PSoC™ 4 Forum Discussions
Hello guys,
I know that this a common error when you are working with i2c and already looked through the all mentioned topics here in community.
Now about the problem:
I'm using max30205 temperature sensor. It's quite simple, only 3 config registers and 1 register with a temperature result.
I was using as a referal example from here https://github.com/cypresssemiconductorco/PSoC-4-BLE/tree/master/100_Projects_in_100_Days/Day031_Digital_Sensor
Also I tried another approach with a manual i2c configuration: when you are using I2CMasterSendStart, I2CMasterSendStop. Results are the same: I'm getting an error: bus busy...in some cases when I'm lucky enough some of the initialization steps can be passed but anyway this is not good at all.
Seems like I missed somethig important, like waiting for a bus free before start any activity on the bus, but I didn't find the corresponding status in API to check this.
I really hope that some of you can help me with this problem. Project attached.
Thanks.
Show LessHi,
I have often seen, that the CyBle_ProcessEvents() function is called in the main loop to process the BLE stack work. But in my situation, the cycle time highly depends on the external peripheral and can take more time than my connection interval. So I have to call the CyBle_ProcessEvents() function minimum twice. Right now, I tried to call this function in a timer ISR where my timer period represents an average between the minimum and maximum connection interval. So are there any disadvantages for me or why is it not implemented in any example code?
Thanks!
Show LessI have a system where the BLE stack occasionally gets stuck inside of CyBle_GattsWriteRsp(). I've managed to trace the execution until it enters this function and confirmed that it doesn't return until the system watchdog resets after a few hundred milliseconds.
Here's how the project is structured:
- Main loop performs operations such as I2C and CyBle_ProcessEvents().
- SysTick performs short periodic actions every 1ms. (Priority: 2)
- DMA interrupt performs a few milliseconds of buffer processing around every ~10ms. (Priority: 3)
- BLE BLESS interrupt has priority 2.
There are three watchdogs active,
- Main Loop (256ms timeout)
- SysTick (4ms)
- DMA Interrupt (32ms)
All watchdogs trigger the general watchdog interrupt when they expire. My handler prints which timer expired and then loops. The watchdogs trigger a hardware reset if the watchdog interrupt isn't handled three times, I cause this by never exiting the handler once triggered. (nearly same as a direct watchdog triggered reset, but allows me to print out system state)
The BLE minimum connection interval I'm using is 30ms. I verified that CyBle_ProcessEvents() gets called multiple times within the connection interval, even when pending I2C actions and interrupts queue up together. It typically gets called around every 5-10ms at the longest.
I traced through the system and found that CyBle_ProcessEvents() calls the registered BLE event handler passed on stack init. The issue seems to be fairly rare, but occasionally when I process a CYBLE_EVT_GATTS_WRITE_REQ event, program execution enters the CyBle_GattsWriteRsp() call and remains there until the 256ms main loop watchdog resets the system. Note that interrupts are operating correctly since their watchdogs aren't what resets the system.
I can't check error flags returned from the BLE stack since the function never returns. My SysTick interrupt does occasionally call CyBle_GattsWriteAttributeValue() and CyBle_GattsNotification() and I thought that one of these occurring when main is in CyBle_ProcessEvents() could be causing the lockup. I instrumented the system so I could see when these calls occur and it doesn't appear that the lockup is triggered by one of these functions being called from an interrupt during CyBle_GattsWriteRsp().
I think that the lockup is a symptom of a larger issue with how I am handling the BLE stack. Sometimes the device momentarily delays or stops responding to BLE connections even though CyBle_ProcessEvents() is still being called regularly.
If anyone has any ideas to try I would be really grateful, I can't post the actual project here but I'm providing a stripped version of my BLE handler C file.
Show LessI am going to build em_eeprom with sflash. I verify the .scat file according datasheet, but can't run at sflash. ( 0x0ffff200 of 4100PS), can't fix address. Please give me some advice.
Thank a lot.
Haixian
Show LessHello, I am using ASR6501 chip. Do you have a schematic of lora
Hi,
I have a few technical questions in regards of your IO expander chip. Looking closer at the register factory default settings, it appears that from start up all GPIO’s are configured as output and not inputs, that raises a little concern? Could we obtain more detailed information on the Drive Mode Registers. Currently they are set 0x1D to 0xFF which means that all the GPIO are Resistive high, strong low. Any chance that someone can explain this a bit better. Does this mean that a GPIO has a high resistor value to VCC and requires a strong low signal in order to pull the GPIO to a Low level?
Anyway would be good to find out more details about the options.
With Regards
Matthias
Show LessHello everyone,
Could someone please confirm whether or not there are pull-up resistors within the module for this kit. I'm specifically interested in the connections for the User Button(connected to pin p2.7). From the schematic of the module and the board itself there doesn't seem to be any external resistors. However, while using the PSOC creator software, the schematic for the User Button displays a pull-up resistor. Is this pull-up resistor-contained within the module ?
Kind regards,
Alisha Khan
Show LessHello,
Cuurrently we are using the BLE module CYBLE-222014-01 in our design, and now we are looking for discrete BLE chip solution,
I thought the IC CYBL10573-56LQXI is best one, but that IC is getting obsolete. Please let me know the best suitable replacement BLE IC for the module CYBLE-222014-01 and that requires fewer software changes.
Thanks,
Naga.
Show LessI've created a fresh project based on the fixed stack Bootloader / Bootloadable projects and have an issue with readable data from the UART TX. I've made sure my UARTs are set for 57600 on both projects and made sure to read at 57600 from my terminal apps(tried multiple, putty, screen). I'm using the included UART debugging code in both projects with the same results. Could my baud rate still be an issue here and if so, how can I calculate or find what my baud rate should be?
I do see data in the terminal but it looks like a baud rate issue no what what baud rate I try. I've tried all preconfigured rates, 9600 - 115200 on both projects and terminal.
screen -L /dev/tty.usbserial-14630 57600
^S/]P]*P\_P^X,,]^P[,1ƣ^S/]P]*P\_EqQ1EQ11QqE^S/]P]*P\_VP1QqEP+]Wc$ODa3fX+bD$1ƣX+bD$1Fƣ
My project settings are all default.
#define DEBUG_UART_ENABLED (YES)
/* YES - use printf, NO - use UART_PutString
* e.g. DBG_PRINTF("message %d\r\n", i) will transform to UART_PutString("message %d\r\n") */
#define DEBUG_UART_USE_PRINTF_FORMAT (YES)
Show LessHi,
I try to configure a basic (just sleep mode) low power mode for the CYBLE-212006 BLE module. I started with the 100 projects in 100 days Project: "Day041_PSoC_4_BLE_Low_Power_Modes".
This is the important piece of code:
void HandleLowPowerMode(uint8 lpmSel)
{
#ifdef ENABLE_LOW_POWER_MODE
/* Local variable to store the status of BLESS Hardware block */
CYBLE_LP_MODE_T sleepMode;
CYBLE_BLESS_STATE_T blessState;
if (lpmSel == DEEPSLEEP)
{
...
}
else if (lpmSel == SLEEP)
{
/* Leave chip in Sleep mode */
/* Leave chip in Deep Sleep mode */
/* Put BLESS into Deep Sleep and check the return status */
sleepMode = CyBle_EnterLPM(CYBLE_BLESS_SLEEP);
/* Disable global interrupt to prevent changes from any other interrupt ISR */
CyGlobalIntDisable; <---------------------
/* Check the Status of BLESS */
blessState = CyBle_GetBleSsState();
if(sleepMode == CYBLE_BLESS_SLEEP)
{
if(blessState != CYBLE_BLESS_STATE_EVENT_CLOSE)
{
/* If BLE Event has not
* closed yet, then place CPU to Sleep */
#ifdef ENABLE_LED_NOTIFICATION
BLUE_Write(0);
BLUE_SetDriveMode(BLUE_DM_STRONG);
#endif
CySysPmSleep();
#ifdef ENABLE_LED_NOTIFICATION
BLUE_SetDriveMode(BLUE_DM_STRONG);
BLUE_Write(1);
#endif
}
}
/* Re-enable global interrupt mask after wakeup */
CyGlobalIntEnable;
}
else if (lpmSel == ACTIVE)
{
...
}
#endif
}
The code make sense and I think there are no problems to implement it. But why are the interrupts disabled before entering the SleepMode? Is it possible to enter the SleepMode without disabling the interrupts and using BLE? What does: "to prevent changes from any other interrupt ISR" mean? I'm using some critical peripherals (868 MHz radio cpu) and don't want to disable all isr's.
Thanks!
Show Less