6 Replies Latest reply on Feb 14, 2019 5:18 PM by GeEd_1216226

    PSoC 6 CY8CKIT-062-BLE shuts down

    GeEd_1216226

      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.

        • 1. Re: PSoC 6 CY8CKIT-062-BLE shuts down
          ShipingW_81

          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.

          • 2. Re: PSoC 6 CY8CKIT-062-BLE shuts down
            MeenakshiR_71

            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

            • 3. Re: PSoC 6 CY8CKIT-062-BLE shuts down
              GeEd_1216226

              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

              • 4. Re: PSoC 6 CY8CKIT-062-BLE shuts down
                ShipingW_81

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

                • 5. Re: PSoC 6 CY8CKIT-062-BLE shuts down
                  GeEd_1216226

                  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

                  • 6. Re: PSoC 6 CY8CKIT-062-BLE shuts down
                    GeEd_1216226

                    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

                    1 of 1 people found this helpful