• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 294 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 on PC relative read

Ulf Samuelsson
Expert 1010 points
Part Number: TMS570LC4357

We have seen data aborts happening.

The always seems to happen when the CPU is reading a pointer from memory.

LD Rn, [PC, #imm]

LD Rn, [Rn]

...

imm:  DC32 address

When the first instruction executes, the data abort happens when accessing the "imm" variable

In one case, this is in a subroutine.
This code is called multiple times.

In two places, it generates a data abort, but only when running at full speed.
If I single step through the code, the data abort does not happen.

In other places, I have not seen the bug.

We are using the Parameter Overlay Module, and remap the first 64 kB to SRAM to allow flash programming (It is a bootloader)

The first subroutine that exhibits this problem, runs maybe 20 instructions after POM has been enabled.

The second subroutine runs maybe 20 seconds after the POM has been disabled.

===

I have seen the problem in another place.

This is right after a call to the F021 library has returned.

I am then checking the status through a pointer and it the code has the same pattern.

In this case, both full speed execution and single stepping will cause a data abort.

The POM is enabled in this case, and the CPU should be executing in the first 64 kB, but the POM remaps this to internal SRAM.

I found a workaround, which is to create a __ramfunc subroutine which I jumo to. Then I do not get an abort.

===

The third place where we have seen the problem does not use the POM at all.

When the bootloader starts the application, it passes a parameter to the application
indicating a POWER ON RESET. The application then asserts a S/W reset which
will return the CPU to the bootloader which will not do a full initialization.
Only the stacks and the general purpose registers are initialized before calling the application
again, now passing S/W RESET as a parameter, and the application starts real execution.

The applicatino never touches the POM.

The data abort now happens in an SVC. This SVC is setting the CPU in System Mode. PSR.M[4:;0} = 0x1F.

This is bound to be executed many many times, but after 1 hour a data abort occurs.

We would appreciate ideas on this one!

  • 0
    TI__Guru**** 197186 points

    Hi Ulf,

    Just saw your post, I will check it tomorrow. Apologies for delayed response.

  • 0 in reply to QJ Wang
    TI__Guru**** 197186 points

    Hello Ulf,

    The POM module is designed to be used during development, you can think it as a debug module.

    For the SVC exception, did you call SVC from your application? How does your bootloader pass the parameters to the application image?  

  • 0 in reply to QJ Wang
    Expert 1010 points

    The bootloader starts and checks reset reason.
    If POWER_ON_RESET, it will runs initializations.
    It checks a pin (GPB_BM), and if this pin is not asserted, the bootloader attempts to start an application.
    An application header is checked, and if magic words are OK and CRC checks succeed
    the application entry point is read from the header:
       /* Check header */
        vectors=app->vectors;
        application=vectors->reset_handler;
        (*application)(POWER_ON_RESET);

    The application checks the parameter, and if POWER_ON_RESET, it will issue a SW_RESET.
    The bootloader checks the reset reason, since it is SW_RESET, it will call the application without initializing the chip.
        (*application)(SW_RESET);

    The application will now run, with minimal initialization which means that self-tests will complete.

    Note that POM is never initialized here.
    If the GPB_BM pin tested is asserted, the bootloader copies itself to SRAM,
    enables POM and runs the bootloader CLI.
    When ready to start an application, the bootloader CLI is exited, and the POM is disabled.

    =====

    The application performs an SVC to access OS functionality. In this case the SVC sets the mode to system mode.
    The way this is implemented is that the SVC handler is implemented in the bootloader.
    The bootloader checks a magic word in the application header location.
    If the magic word check succeeds, the bootloader assumes there is a valid application.
    Right after the header, is an exception table (which is not used by H/W, H/W uses the bootloader exception table)
    The application exception table has eight entries and the SVC entry is loaded into the program counter.
    After that, the CPU is executing in the application SVC handler.

    The Cortex-R5 support remapping the exception vector table to another location,
    but TI choose to put a peripheral there, so this is useless.
    The address of this location is a parameter to the chip design, so it is possible to put it elsewhere.
    If a revision is ever done, then this would be good to have fixed.

    Anyway, nowhere in the normal path is the POM enabled.

  • 0 in reply to Ulf Samuelsson
    TI__Guru**** 197186 points

    Thanks Ulf for your detailed description. You are correct that the Hercules devices don't support relocating the exception vector t another location. The exception vector located at the beginning flash is used by both bootloader and application. 

    If bootloader doesn't use SVC, you can modify the SVC branch address to your application. 

    If both bootloader and application use SVC, the bootloader exception vector needs to jump to the address (not a function name) of the SVC hander in bootloader, the SVC hander will decide where to jump (bootloader, or application). To be honest, I didn't try this before.