• Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 1077 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.

When PBIST enabled hex470 is skipping some bytes in memory

Denis-24
Prodigy 90 points
Other Parts Discussed in Thread: HALCOGEN, TMS570LS3137

Hey,

I've got the following issue. I'm providing a custom bootloader, which loads an application through SCI. After building the application in CCS I'm creating an intel hex file with hex470. When the option "Enable PBIST Self Check" is disabled in HALCoGen the application is running well. I'm getting the following content in memory and hex file:

When PBIST Self Check is enabled, there are zeros at 0x0002A754 which do not appear in the generated hex file. See Screenshot:

Further Information:

HALCoGen version: 04.02.00

TMS470 HEX Converter: v4.9.9

Target: TMS570LS3137

How can I fix that?

Regards

Denis

  • Prodigy 90 points
    I've tried that with CCSv6 and armhex v5.1.6. Same thing with the zeros.

    Nobody an idea?
  • in reply to Denis-24
    TI__Mastermind 49120 points
    I will get this info to the team supporting the armhex utility. In the mean while can you try generating the hex file without the "-fill 0" option? The -fill option is ignored unless you use the --image option as well.

    Regards,
    Sunil
  • in reply to Sunil Oak
    Prodigy 90 points

    Hello Sunil,

    same thing without the "-fill 0" option.

    Regards,

    Denis

  • TI__Guru**** 251230 points

    I cannot tell you the root cause of your problem.  But I think I can shed some useful light.

    Intel hex format is described in the section titled Intel MCS-86 Object Format in the ARM assembly language tools manual.  I carefully pieced together the meaning of the Intel hex in the second build.  The address 0x0002a754 is skipped over; no output is described for that address.  It makes sense that it gets filled with 0.  

    So the question changes to: Why is there a 4-byte memory hole at 0x0002a754?  It may legitimately be a hole, or it may not.

    Here is one scenario which shows the hole is legitimate.  What is the length of the data object q_shifts?  Since p_shifts is 8-bytes long, it is a good guess that q_shifts is also 8-bytes long.  Just for now, assume q_shifts is 8 bytes long.  What entity (code or data) is immediately after q_shifts?  We don't see the symbol name in the memory window.  But that is not surprising.  It could be the start of some static (not global) entity.  Perhaps that entity requires 8-byte alignment.  Note that all the addresses in the second build are +4 bytes when compared to the first build.  In the first build, the address of the unknown entity is 0x0002a750.  That is an 8-byte aligned address.  Without alignment, the corresponding address in the second build is 0x0002a754, which is not 8-byte aligned.  To achieve 8-byte alignment, the compiler or linker arranged for this entity to be 8-byte aligned.  This alignment requirement is always present.  In the first build, this alignment requirement does not result in a 4-byte hole. In the second build, it does.

    That is only one possible scenario.  There is not enough evidence to say whether it is correct.

    It would help to know the names and addresses of everything around the addresses 0x0002a750 and 0x0002a754.  You can see that by using the name utility.  This is a command line utility.  This command would do it ...

    % armnm -a -n TMS570LS3137-Applikation.out

    The option -a says to output all the symbols.  The option -n sorts the output by address.

    Thanks and regards,

    -George

  • in reply to George Mock
    Prodigy 90 points
    Hello George,

    I've got handled my issue. The zeros were not the problem. I have a custom bootloader and an application with the following setup for self tests in HALCoGen:

    Bootloader: ESRAM ECC Check disabled, PBIST Self Check enabled
    Application: ESRAM ECC Check enabled, PBIST Self Check enabled

    If I disable all self tests in application, the program is running.
    Also if I enable all self tests in application and bootloader, the program is running.
    If I disable all self tests in bootloader, the program is running.

    So thanks a lot for help.