Can you please show more details? Have you ever tried other demo codes and if all they get stuck after running a while? Is there a normal case? If no code get fine running, the issue should lie in hardware.
If you have debug enabled, (default) can you please provide a snapshot of the call trace when the device hangs? Run the firmware and when it hangs, go to "Debug>Attach to Running target" in the PSoC Creator project and connect to M4. This should tell where the code is stuck. You can post it to this thread, if possible, along with the project. This would be helpful to debug the issue.
Also, if you are running some code in M0+ (which can impact the application flow), then attach to M0+ as well and provide the call stack. Call stack window can be opened by selecting "Debug > Windows > Call stack".
Meenakshi Sundaram R
Thanks for your guidance. I managed to capture one of the issues, which is difficult because I have 4 x PSoC6 systems connected to do these tasks. As it shows above, there is an issue that has arisen within the handleInterrupt() routine which is part of a library for running Lora radio modules. Perhaps there are colliding signals. I will investigate this to see what I can find. Unfortunately I cannot share the project because it is a dynamic mesh networking system for Lora that is commercially sensitive. But perhaps it is a FIFO overflow error, so I need to empty buffers I believe.
What's the current situation? Have you get this issue solved?
I have been trying to narrow down the point of error where it goes into a loop.
// Cy_SCB_UART_PutString(DEBUG_UART_HW,"\r\n Pre- Block");
Cy_SCB_SPI_WriteArrayBlocking(SPI_LoRa_HW, BufferTX, len+1);
// Cy_SCB_UART_PutString(DEBUG_UART_HW,"...post Block");
while((Cy_SCB_SPI_GetNumInRxFifo(SPI_LoRa_HW) < (len+1)) );// Wait until transmission is completed
This is an SPI device, so when it goes into the final while() condition, obviously not all data to len+1 is being read and it just loops. It always fails with the last message “…block” but never gets past the while condition.
I wrote a few debug lines so that I could narrow down the point of error as shown above.
I am wondering if this is a particular issue with SPI SCB on PSoC 6, but I am trying some work-around for it so that if it does not retrieve all len+1 data, it exits.
Thanks for following it up. I am still trying to test my solutions, but any suggestions are welcome and appreciated.
Dr Geoff Edwards
Applied Resolution Technologies
Lot 521 Sullivans Road
YAMBA NSW 2464
(02) 6645 8868
1 of 1 people found this helpful
SOLUTION : Finally I managed to fond a test that showed me the issue/solution. I assumed that I had 14 bytes being transferred via SPI from an RF95 radio module which is the maximum I should have. For hours, this was the case. But sporadically it would think there were 170+ bytes of data, which seems to be random error from the RF95 module via SPI. The PSoC6 system was sitting there trying to retrieve false data from the buffer when it never existed......so solution was to put error checking into the system to limit the data to 16 bytes or something, and ignore any errors from the SPI device.
Problem now resolved, perhaps not pretty but at least it is now running. Image below shows some quick debugging and shows in this case 188 bytes instead of 14 bytes. The other block..pre-block etc statements were inserted to narrow down where the system was failing.