Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
GeEd_1216226
Level 4
Level 4
25 replies posted 10 replies posted 5 replies posted

Using the above kit.  Initial application involves UART, CAPSENSE, I2C, SPI devices, quite complex.  In 2 configs that I have been developing, after a period of time the program stops working.  I am now using FREERTOS to run tasks but this issue happened before FREERTOS as well.

I don't have any specific counters etc that might be overflowing, that I know of, but after about 5-10-15 minutes, the program just freezes.  I am after suggestions as to what I should look for as a cause.  It is perhaps going to sleep, but in most cases there is activity in the process (sending Lora signals for example) which show me that the program stops.

If it might be a "sleep" mode, how would I disable???  The system runs OK if I hit the reset.  I am expecting the application to run forever when power is applied.

0 Likes
1 Solution

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.

RF61.png

View solution in original post

6 Replies
ShipingW_81
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

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.

0 Likes
MeenakshiR_71
Employee
Employee
100 likes received 50 likes received 25 likes received

Hello,

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".

Regards,

Meenakshi Sundaram R

0 Likes

stack error.png

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.

stack error2.png

0 Likes

What's the current situation? Have you get this issue solved?

0 Likes

Hi,

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

<http://www.appliedresolution.com.au/> http://www.appliedresolution.com.au

Lot 521 Sullivans Road

YAMBA NSW 2464

(02) 6645 8868

0407542440

0 Likes

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.

RF61.png