• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 682 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: Data Abort when Debugging

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

Hello,

I've recently come across a problem that I'm struggling to resolve.

For background, we have developed a custom BootLoader which resides in Flash Bank 0, and we have modified our Application's memory allocations through the linker command script to utilize Flash Bank 1. This scheme has been stable and worked reliably for the past year or so. However, a few months ago, there was an update to Halcogen (4.7.0 -> 4.7.01) which caused some BootLoader <---> Application issues. I won't go into detail here, but the solution we found was to modify the HL_sys_startup.c in the application to perform necessary initialization, as the BootLoader will clear any reset sources. Let's call the pre-Halcogen update Application v1.0, and the post-Halcogen update Application v2.0. Application v2.0 was tested and seemed stable.

Now, the problem we're seeing today is that when using the Debugger, we encounter a Data Abort exception in Application v2.0, but NOT Application v1.0. this abort is repeatable, and I've been able to gather the following data:

  • The abort always happens when attempting to read a peripheral register (ADC, N2HET, etc.)
  • The DFSR reads 0x00001008, indicating an External reset by an AXI Slave device during a Read
  • The DFAR reads 0xFFF7C004. The abort happens when reading the OPMODECR register of ADC1.
  • The Auxiliary DFSR reads 0x00500000, which indicates an AXI peripheral port caused the abort

What's odd is that this only happens when debugging. When building the application and programming through the BootLoader, this issue isn't seen. Additionally, this issue isn't seen in Application v1.0.

Some additional information:

  • We are using the XDS110 Debug probe native to the Hercules LaunchPad
  • My CCS environment seems to have been corrupted. For some reason, I've had to modify each one of my projects and manually add a binary image to flash when debugging/flashing (before, this had been handled automatically). I'm unsure of how/why. My only guess is that I installed some Hercules sample projects, and it included an installation of "nowFlash" which seems like a legacy microcontroller flashing app. Maybe this has hooks in the CCS environment?

Any help would be appreciated.

Thank you,

James

  • 0
    TI__Guru**** 198906 points

    Hi James,

    Is this your test sequence to produce the issue:

    1. Bootloader is in flash locating in 1st sector

    2. you program the application image to application area (not 1st sector) through CCS rather than bootloader

    3. CCS system reset, 

    4. code jump to application through bootloader (JTAG is still connected)

    5. get abort when reading OPMODECR register of ADC1.

    But there is no issue when booting from bootloader

    1. Bootloader is in flash

    2. Application image is programmed to application area through bootloader

    3. system reset or SW reset after the application image is updated   --- no JTAG connection

    4. code jumps to application, and executing the application code    --no JTAG connection

    The issue might be caused by the CCS and Emulator drivers. Can you re-install the whole CCS package?

  • 0 in reply to QJ Wang
    Intellectual 380 points

    Hello QJ,

    Thank you for the reply. I was actually able to solve the issue, it was due to my application not correctly handling Debug Resets in the startup routine. 

    Thanks,

    James