CY_NORETURN is called when an interrupt occurs that is unhandled by a function. Usually caused by either: Forgetting to set a callback function for an interrupt, or for calling one of the BLE APIs when the BLE device is not started/ready.
Since your BLE API calls look okay, I would expect it to be an interrupt for one of the serial components.
Double check that you have the ISRs setup for the SPI and UART components, and that they are functioning correctly.
Also, you can try moving the CyBle_Start(CustomEventHandler); line until after Initialize(); to see if that helps fix something.
Thank you for your response. When the BLE start code is removed, the software works fine and all interrupts do what they need to do. When it is added, wherever it is added, it ends up crashing into the CY_NORETURN. Any other suggestions?
Hmmm, if it is indeed the CYBLE module API calls crashing the unit, then I would suggest checking the return values from each one to make sure they all execute successfully.
You can also try commenting out the cyble api calls one by one to see which one in particular is causing the crash too.
I was hoping it was a regular interrupt crashing the unit, but apparently not :(
I'll give a more detailed look through the project and see if I can spot an incorrect BLE api call. That would be where I would focus on looking at this point.
Try checking the return values of the CyBle_ calls you are making in the CustomEventHandler() to see if any of them return anything except Cyble_error_ok;
Check and see if you are getting an unhandled event on the CustomEventHandler(), like an HCI error event or something.
Also, it looks like you are writing to the flash using the emulated EEPROM, which is fine, but if you write values to it while the BLE radio is active, it will interfere with it heavily (and be the cause of the crash I would assume). Looking at the code, you are only calling it on bootup, but just keep in mind that running them both at the same time could cause issues with timing.
Thank you for the feedback. I started a case with Cypress, and they got back to me very quickly (thank you!). The issue that they pointed to was in the EEPROM code that I had adapted for PRoC.
=> Issue was with Em_EEPROM.c file. I think you have copied the file from any PSoC 4 device. However, this won't directly work with BLE part number. For making it work with the same, you need to update the rowId correctly as rowId = arrayId * (CY_FLASH_SIZEOF_ARRAY/CY_FLASH_SIZEOF_ROW) + rowId; Attached the modified file along with the interaction.
They also recommended the following:
Make the BLE_bless_isr highest priority
Make the heap larger - 0x200
That said, why would accessing the EM_EEPROM affect the BLE radio?
1 of 1 people found this helpful
Since the EM_EEPROM runs by reading/writing data to the Flash location on the chip (either SFLASH or code FLASH), then it requires 48 MHz to write new data to the flash; This will affect the BLE radio if you are not running the device at 48 MHz, as the chip will temporarily freeze the clock in order to change it to the higher frequency, and again when it changes it back.