• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 549 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: HALCOGEN Update Breaks Code

James Kiessling
Intellectual 380 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Hello,

My HALCOGEN software was recently updated to version 4.7.1 from 4.7.0. We had been using the tool to create the HAL code for our project, starting in version 4.7.0. However, after the update, generating the HAL code in the tool causes the application to not work correctly.

I've verified that it's the HALCOGEN tool using our version control system:

1) Revert code back to stable build (including HAL files generated using 4.7.0)

2) Build and program device through our custom BootLoader, verify correct behavior

3) Re-generate the HAL code using the project's unmodified .hcg file in HALCOGEN 4.7.1

4) Re-build and program through custom BootLoader 

After step 4) above, the BL jumps to the application correctly, but the application crashes at an unspecified time (I say unspecified because it's seemingly random where it crashes). Now, the odd thing is that the application works correctly when we flash the controller directly through the JTAG port, rather than programming through the BL (using Motorola S2 record format).So, we can't use JTAG debugging to determine the point of failure in the code, making it even more difficult to debug.

Of course, one solution to the problem would (could) be to revert back to HALCOGEN v4.7.0, but I would like to keep my toolchain updated as much as possible, so I would like to try and figure out why this update is causing this issue.

Thank you,

James

  • 0
    Intellectual 380 points

    Update: I've narrowed the problem down to a problem with jumping from the BootLoader to the Application. What we had done before (naively) was to prevent the BootLoader from clearing the SYSESR register in its initialization sequence, so that the application can read the register, obtain the reset source, and initialize the VIM/IRQ. We had accomplished this by modifying the getResetSource() function of the file HL_system.c, removing the code that clears the SYSESR register for POWERON_RESET and EXT_RESET reset sources. 

    After doing some digging, I noticed that the files produced by HALCOGEN 4.7.1 differ in their handling of reset sources - both in the getResetSource() function of HL_system.c and in the _c_int00() function of HL_sys_startup.c. This leads me to conclude that this is very likely to be the source of our error. This would also explain why this error doesn't occur when flashing the application directly through a JTAG Debug probe. 

    Again, I recognize that our previous "solution" for jumping to our application was naive. If anyone has advice on how we should properly facilitate launching the application in our BootLoader, or how to otherwise modify the HAL code to suit our needs, it would be much appreciated.

    Thank you,

    James

  • 0 in reply to James Kiessling
    TI__Guru**** 198766 points

    Hello James,

    Your application may need memory initialization. The sys startup from 4.7.01 doesn't initialize the SRAM if the reset source is not power-on reset. Please add _memInit_() after switch(rstSrc){} in sys_startup.c.

  • 0 in reply to QJ Wang
    Intellectual 380 points

    Hello QJ,

    Thanks for the reply. Unfortunately, this did not solve the issue. My intuition tells me that it's not a problem with initializing SRAM, because the BootLoader executes correctly. I'm able to program a new application through the BootLoader, for example. 

    I've done a few more tests and have some more information:

    1. When I power cycle the device and launch the application, the actual application is not entered - the program crashes somewhere during the HAL initialization routines.
    2. If I re-flash the BootLoader onto the device, and from there launch into the application, the application executes correctly.
    3. If I re-flash the BootLoader, launch into the application, and trigger a software reset, the BootLoader is executed
    4. If I execute step 3, then jump to the application once more, my application does not crash, but the RTI module no longer flags any notifications (possibly due to VIM/IRQ initialization failure?)

    From what I understand, using a JTAG Debug probe to flash code triggers an external reset, while power cycling triggers a Power-On Reset. I'm seeing different behavior of my application/BL in these scenarios, which leads me to believe that my handling of the reset sources and reset flags is causing issues. I'll continue to investigate this path; please let me know if my assumptions are off-base.

    Thank you,

    James

  • 0 in reply to James Kiessling
    TI__Guru**** 198766 points

    Hello James,

    I mean to initialize the SRAM in application. Another suggestion, please disable the interrupt in bootloader before jump to application.

  • 0 in reply to QJ Wang
    Intellectual 380 points

    Hello QJ,

    My application initializes the SRAM, and the BootLoader disables interrupts before jumping to the application.

    I've solved part of the issue - it had to do with how I was handling resets (power-on, external, etc.) in the BootLoader and the Application. However, there's one more problem: the application has the ability to trigger a software reset (by writing to the SYSECR). The code now crashes when executing the BootLoader code after the software reset, and I believe that this has to do with how reset sources are handled. 

    In the generated HAL files, there is no code to handle device initialization after a software reset, and I have not found details of how a software reset is handled in the documentation. Where in the documentation is this detailed? I would like to know what hardware must be initialized after a software reset, etc.

    Thank you,

    James

  • 0 in reply to James Kiessling
    TI__Guru**** 198766 points

    Hi James,

    If you issue software reset from bootloader instead of application, does the code crash? 

    What does the crash mean: data abort, prefetch abort, other uncorretable error?

  • 0 in reply to QJ Wang
    Intellectual 380 points

    Hello QJ,

    Good news! I seemed to have solved the issue. I'll discuss what the issue was in case others reading this post come across this.

    The source of the issue was indeed the handling of reset sources. Initially, I had written the BootLoader to not clear the source of the reset, so that when jumping to the application, the application would perform certain hardware initializations that were necessary for operation (such as configuring the IRQ offset for peripheral interrupts). When the newer version of HALCoGen (4.7.01 compared to 4.7.0) generated the source code, two key files were changed: HL_sys_startup.c and HL_system.c. In 4.7.0, the function getResetSource() would stop executing on the first reset source seen, clear the resource, and return that source. In 4.7.01, in the case of an external reset (EXT_RESET), the EXT_RESET is cleared, but the code continues to search for a preceding reset source (OSC_FAILURE, WATCHDOG, SW) and it clears and returns that reset source. 

    This was the cause of my problem. When a software reset would occur, my 4.7.0 BootLoader would read an EXT_RESET, but 4.7.01 would read a SW_RESET. I had to add hardware initialization code to the case of a SW_RESET in the switch(rstSource){}. 

    In the application, because I modified the BootLoader to handle all reset sources, I disabled the switch(rstSource){} and added necessary application-level hardware initializations only:

    Thank you,

    James