1 2 3 Previous Next 36 Replies Latest reply on Mar 16, 2020 3:54 AM by LePo_1062026

    Program points to  null in disassembly while debugging

    SAJO_1338106

      While debugging my program, I found that the pointers gets lost and could not trace the current statement when halted. Disassembly opens and points to one of the sub routine. Note that I have I2C sensors connected. They gave output as follows at the USBUART:

       

      "Temp = 26580 Humidity = 35596 UV = 1 LW = 65533 IR = 65535

       

      HDR Address 64 Temperature = 00046,0223124215, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, MPPT A = 40 B = 35 C = 38 D = 36 Pmax A = 88 B = 86 C = 85 D = 29 Temp = 26584 Humidity = 35468 UV = 0 LW = 65534 IR = 0

       

      HDR Address 64 Temperature = 00046,0223124225, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, MPPT A = 49 B = 35 C ="

       

      But all of the sudden, it program window opens to Disassembly and I could not see the program pointer. Though I can run and halt but nothing happens.

      "

      673:                                    

      674:                                        if((atoi(hour)> 7) && (atoi(hour)<19) && (RTC_1_ReadMinute() != (u_short)atoi(min)))

      0x0000172E add r0, sp, #54 ; 0x54

      0x00001730 bl d6a0 <atoi>

      0x00001734 cmp r0, #7

      0x00001736 ble.n 1790 <CYDEV_DMA_SRAM16K_MSIZE+0x790>

      0x00001738 add r0, sp, #54 ; 0x54

      0x0000173A bl d6a0 <atoi>

      0x0000173E cmp r0, #12

      0x00001740 bgt.n 1790 <CYDEV_DMA_SRAM16K_MSIZE+0x790>

      0x00001742 bl 464c <RTC_1_ReadMinute>

      0x00001746 mov r5, r0

      0x00001748 add r0, sp, #58 ; 0x58

      0x0000174A bl d6a0 <atoi>

      0x0000174E uxth r0, r0

      0x00001750 cmp r5, r0

      0x00001752 beq.n 1790 <CYDEV_DMA_SRAM16K_MSIZE+0x790>

      675:                                        {

      676:                                            RTC_1_WriteMinute((u_short)atoi(min));

      0x00001754 add r0, sp, #58 ; 0x58

      0x00001756 bl d6a0 <atoi>

      0x0000175A uxtb r0, r0

      0x0000175C bl 4604 <RTC_1_WriteMinute>

      677:                                            UART_1_PutString("Minutes updated\n");

      0x00001760 ldr r0, [pc, #1cc] ; (1930 <CYDEV_DMA_SRAM16K_MSIZE+0x930>)

      0x00001762 bl 4d54 <UART_1_PutString>

      678:                                            EEPROM_1_UpdateTemperature();

      0x00001766 bl 5090 <EEPROM_1_UpdateTemperature>

      679:                                            EEPROM_1_Write2Byte((u_short)atoi(date)*100+(u_short)atoi(hour),SYNC_ADDRESS);

      0x0000176A add r0, sp, #5c ; 0x5c

      0x0000176C bl d6a0 <atoi>

      0x00001770 mov r5, r0

      "

      Output window log:

       

      "

      Device 'PSoC 5LP CY8C5868AXI-LP035' was successfully programmed at 02/24/2020 18:01:18.

      Continuing target program

      The target program has stopped at: file: main.c line: 904 function: main address: 0x00001BF8

      Continuing target program

      The target program has stopped at: file: main.c line: 1056 function: main address: 0x00002018

      Continuing target program

      The target program has stopped at: file: main.c line: 674 function: MyRxInt address: 0x0000172E

      Continuing target program

      The target program has stopped at: file:  line: -1 function: USBUART_TABLE address: 0x0003EF74

      Continuing target program

      The target program has stopped at: file:  line: -1 function: USBUART_TABLE address: 0x0003EF74

      Continuing target program

      The target program has stopped at: file:  line: -1 function: USBUART_TABLE address: 0x0003EF74

      Continuing target program

      The target program has stopped at: file:  line: -1 function: USBUART_TABLE address: 0x0003EF74

      Continuing target program

      The target program has stopped at: file:  line: -1 function: USBUART_TABLE address: 0x0003EF74

      Continuing target program

      The target program has stopped at: file:  line: -1 function: USBUART_TABLE address: 0x0003EF74

      Continuing target program

      The target program has stopped at: file:  line: -1 function: USBUART_TABLE address: 0x0003EF74

       

      "

      Please find the attachment containing my project.

       

       

      Appreciate any assistance.

        • 1. Re: Program points to  null in disassembly while debugging
          RakshithM_16

          Hi SAJO_1338106,

           

          When I build the project I am getting an error stating that some files are missing as shown -

          I was unable to find FS.h in the archive shared.

          Can you please re-attach the project?

           

          Thanks and Regards,

          Rakshith M B

          • 2. Re: Program points to  null in disassembly while debugging
            SAJO_1338106

            Hi Rakshith,

             

            Could you please try now? I have reattached the my project.

            • 3. Re: Program points to  null in disassembly while debugging
              SAJO_1338106

              Hi Rakshith,

               

              Just follow the instruction given in the datasheet of the emfile component

              to generate FS.h.

               

              When using the GCC toolchain, you must specify the directory where the

              library file is located.

              The steps to create the emFile project for PSoC 5LP application using GCC

              toolchain are as

              follows:

              1. Decide which library you need. This decision is based on whether you

              need FAT12/16 or

              FAT32, whether your application uses an OS, and whether you need long file

              name

              support. This example uses emf32nosnlfn.lib (FAT32, no OS, and no long file

              name

              support).

              2. Select the necessary include file directory. Go to Project > Build

              Settings > ARM GCC

              4.8.4 > Compiler > General. Click the “…” button in the Additional Include

              Directories

              property field. The Additional Include Directories dialog will display.

              Click the New

              button and select an include directory for PSoC 5 and an include directory

              for the specific

              options you want.

              Note If want to run the project in both “Debug” and “Release”

              configurations you need to

              add the Include Directories for both configurations.

              3. Go to Project > Build Settings > ARM GCC 4.8.4 > Linker > General >

              Additional

              Library Directories. Click the “…” button in the Additional Library

              Directories property

              field.

              The Additional Library Directories dialog will display.

              4. Click the New button and select the library directory for the GCC

              library.

              Adding Library Directory

              5. Specify the library in the library directory.

              a. Go to Project > Build Settings > ARM GCC 4.8.4 > Linker > General >

              Additional

              Libraries.

              b. Type in the library name without prefix "lib" and suffix ".a" (for

              example,

              "libemf32nosnlfn.a" would be "emf32nosnlfn"). This is because GCC

              compiler will automatically add the “lib” prefix to the library name.

              Note If want to run the project in both “Debug” and “Release”

              configurations you need to

              add the Link library for both configurations.

              6. If usage of OS or logging feature is desired then FS_ConfigIO.c or FS_X_OS.c

              files

              should be added to the project. Details on OS integration and logging

              feature usage can

              be found in the emFile User Guide in Chapters 8 and 9 respectively.

              The mentioned files can be added directly into your project from the

              Code/Source/PSoC5

              directory or copied first to your project directory and added from there.

              The files will

              usually be edited, so you need to decide whether to change the original

              files or a copy

              that is specific to the project.

              The files are added to the project using Project > Existing Item.

               

              Add <FS.h> header file in your main.c function.

               

              • 4. Re: Program points to  null in disassembly while debugging
                LePo_1062026

                SAJO,

                 

                I was finally able to get your project to compile.  I'm having difficulties getting your program to run since I don't have the right CPU or the same peripherals.

                 

                However, I noticed the following:

                • Flash used: 259928 of 262144 bytes (99.2 %).  SRAM used: 54441 of 65536 bytes (83.1 %). Stack: 4096 bytes. Heap: 512 bytes.
                  Wow! This is a VERY FULL program.  You're using 99.2% of FLASH and 83.1% of SRAM.    Suggestion:  Can you reduce your SRAM requirements and increase your Stack and your heap?  You might be running out of stack or heap.
                • I noticed you have 6 ISRs.  I also noticed you are performing a lot of processing in some of them including CyDelay()s.  I hope you don't mind a recommendation from someone with years of experience in embedded design.  I learned LONG AGO (30+ years) from a mentor, always write your interrupt code small and tight.  If you spend too much time in the interrupt, you might lose the next interrupt.  Always get the data or signal that caused the interrupt and signal back to the task level (main.c in your case) that the signal occurred or the data is now stored in a buffer.

                Having said that:  Here's a tool to use in the debugger.  Sometimes it can be a big help when the code "goes off in the weeds".

                When you stop the debugger (manually or using a breakpoint) notice the "Call Stack" tab.  It should indicate the levels of stack at the stop point up to main().

                 

                Once I re-targetted your project to the Device being used for the CY8CKIT-059 board, I got your project running-ish.  Since I don't have your peripherals it is limited.

                 

                What are you using to communicate (HMI) with the application?  UART_1 or USBUART?   I'd say it was UART_1 since you have a UART_1_GetChar().  It does look like you are using USBUART as a output.

                 

                Len

                1 of 1 people found this helpful
                • 5. Re: Program points to  null in disassembly while debugging
                  SAJO_1338106

                  Hi Len,

                   

                  Advice well taken.

                   

                  Stack overflow could be the reason.  I am storing the results in flash so it is almost full.

                   

                  I2C devices are required to run the code. I am using ESP for wireless communication and downloading the results through UART and USB for debugging purpose. Program would run without USB.

                   

                  I will decrease the ISR task and re code it in main.c and let you know the results.

                  • 6. Re: Program points to  null in disassembly while debugging
                    MoTa_728816

                    Hi,

                     

                    Reading your main.c, I felt a little bit uneasy about sprintfs.

                     

                    By any chance, can you replace all

                      sprintf(disp,

                    with

                      snprintf(disp, 150,

                    and try if it still caused problem?

                     

                    moto

                    • 7. Re: Program points to  null in disassembly while debugging
                      SAJO_1338106

                      Hi Moto,

                       

                      Any specific reason to use snprintf instead of sprintf? I have ensured that the total bytes never exceeds 132 bytes.

                      • 8. Re: Program points to  null in disassembly while debugging
                        MoTa_728816

                        Hi, SaJo-san,

                         

                        At first I was afraid that there could be a case the total exceeds 150.

                        So it may not help at all.

                         

                        Following are idea(s) off my head... (so may not be quite convincing)

                         

                        Before I had an experience with smaller device (PSoC 4)

                        when the number of arguments exceeded 5 or 6 sprintf caused malfunction of the application.

                        (The length of buffer was enough.)

                        So, I also may try to reduce the length of disp[] and make more sprintf and UART_1_PutString couples.

                        (This also release some sram but may consume more flash)

                         

                        and/or I would  create and try an onion skin function something like

                         

                        ============

                        #define TIMEOUT_LIMIT 5000

                         

                        my_print(char *str)

                        {

                            uint16_t timeout_count  = 0 ;

                         

                            UART_1_PutString(str) ;

                            while(UART_1_GetTxBufferSize()) {

                                timeout_count++ ;

                                if (timeout_count > TIMEMOUT_LIMIT) {

                                    break ;

                                }

                               CyDelayUs(1) ;

                            }

                        }

                        ============

                        moto

                        1 of 1 people found this helpful
                        • 9. Re: Program points to  null in disassembly while debugging
                          SAJO_1338106

                          HI Moto,

                           

                          Yes, this will reduce the SRAM(16% RAM is still available to handle these)

                          but I think that the issue could be something else because the debugger is

                          clueless about the current operating statement. Debugger suppose to have

                          the track recorder of what are the previous states. Strange that the

                          debugger is of no help in this scenario. Anyway, I am rewriting code as Len

                          suggested and share my results.

                           

                          On Tue, Feb 25, 2020 at 10:38 AM Motoo Tanaka <community-manager@cypress.com>

                          • 10. Re: Program points to  null in disassembly while debugging
                            MoTa_728816

                            Hi, Sajo-san,

                             

                            I'm sorry for missing the point.

                            I hope you will be successful with the rewrite.

                             

                            moto

                            • 11. Re: Program points to  null in disassembly while debugging
                              LePo_1062026

                              SAJO,

                               

                              As moto pointed out snprintf() is preferred over sprintf() because it is considered safer by ANSI C.  The 'n' in snprintf() prevents accidentally overwriting beyond the allocated string size thus preventing corrupting RAM.

                               

                              It's great that you're counting the size of the string.  I have on too many occasions just slapped together a sprintf() without counting and found I didn't allocate a large enough string.  Then I wondered why my code went off into the weeds or some variable was nowhere close to what it is suppose to be.

                               

                              Len

                              • 12. Re: Program points to  null in disassembly while debugging
                                SAJO_1338106

                                Hi Len,

                                 

                                Keeping that issue in mind, I had kept extra 20 bytes. Till now, the maximum length was 118 bytes.

                                 

                                Hi Moto,

                                 

                                Glad that you brought this new function snprintf.

                                • 13. Re: Program points to  null in disassembly while debugging
                                  SAJO_1338106

                                  Hi Len, Moto,

                                   

                                  It is been one and half days on the debugger and still running with the following changes.

                                  1. I cut short the ISR of RX and moved the task to main.c
                                  2. Set the master clock to 24 MHz
                                  3. Stack: 8192 bytes. Heap: 4096 bytes

                                   

                                  No issues till now except some UART send receive functionality delay which needs to be worked out with ESP. However, I am still surprised to encounter same issue when the master clock is set to 48 MHz. Am I still missing something here? Is it because of GPIO limitation?  Is there any other alternatives to CyDelay which Len mentioned that I am using so many times which could cause an issue? Kindly advise.

                                  • 14. Re: Program points to  null in disassembly while debugging
                                    MoTa_728816

                                    Dear Sajo-san,

                                     

                                    I just reopened your original project and played with the DWR > Clocks

                                     

                                    To support USB, the device has very accurate 24MHz IMO +/- 0.25%

                                    000-IMO-24MHz.JPG

                                    But if I changed it to 48MHz the accuracy is now +/- 5% which is about the limit of UART to work correctly

                                    001-IMO-48MHz.JPG

                                    and also if you are using USB, the accuracy is not acceptable.

                                    003-IMO-48MHz.JPG

                                     

                                    I wonder if you use IMO 24MHz and use PLL to make it 48MHz, will it make it work better?

                                    002-IMO24-PLL48.JPG

                                     

                                    Best Regards,

                                    27-Feb-2020

                                    Motoo Tanaka

                                    1 2 3 Previous Next