• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 373 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.

DM6437 UART BOOT Freeze

Ohad Shaked
Prodigy 40 points

Hi,


I am trying to boot my simple code via UART to my DM6435 but with no success.

I took the short example given in "spraag0d", I've recompiled it, generated the ais file using the genAIS script and then succeed to load it to my 6435  via Terminal port from my PC.

 

However trying to repeat the same process with my own code fails during boot - the boot just freezes......

My own code is bigger, the size of my bin file (xxx.out) is around 50K and the programming file (xxx.ais) one is 13K.

 

I tried to use the linker.cmd from the "spraag0d" example but no use....

Tried to use the linker.cmd from the EVM6437 test examples with different memory locations mapping but no succsess (see below).

Do you have an idea what could be wrong?

 

Thanks,

 

Ohad.

 

linker.cmd:


-l rts64plus.lib
-l "lib\cams_dm6435bsl.lib"


-stack          0x00001000      /* Stack Size */
-heap           0x00001000      /* Heap Size */

MEMORY
{
    L2RAM:      o = 0x10800000  l = 0x00020000
    DDR2:       o = 0x80000000  l = 0x10000000
}

SECTIONS
{
    .bss        >   L2RAM
    .cinit      >   L2RAM
    .cio        >   L2RAM
    .const      >   L2RAM
    .data       >   L2RAM
    .far        >   L2RAM
    .stack      >   L2RAM
    .switch     >   L2RAM
    .sysmem     >   L2RAM
    .text       >   L2RAM  
    .ddr2       >   DDR2
}

"


  • 0
    TI__Intellectual 2465 points

    Hi Ohad,

    The ROM bootloader uses a small amount of RAM in the internal memory space of the device for stack and temporary buffer/data storage space. Memory is allocated in the first lower 20 K bytes of the L1D (data) CACHE for this purpose.

    - Applications MUST NOT link any initialized code/data sections into this area of memory. Doing so may result in overwriting of essential data used by the bootloader to effect boot; this causes boot to fail. Try to place this sections to DDR2.

    - Un-initialized sections such as the compiler generated sections , .bss, and .far, can be allocated to this area, since these are not populated until after the boot process is complete and the application starts to run. Also, note that the bootloader uses CPU writes to copy downloaded code/data to memory. Becasue of this, the bootlaoder cannot directly load code into the L1P program space. The application must actively populate this space once it has been downloaded.

    This is mentioned in Chapter 5 of "spraag0d".

    Regards,

    Majda

  • 0 in reply to MJovi
    Prodigy 40 points

    Hello Majda,

    Thank you for your reply.

    While waiting for assistance/guidlines, I had some time to read the "spraag0d" and to try different code -> memory allocations, finally succeed to boot from the UART however I'm concerned UART boots only in "FAST"  boot mode and not in "Normal" boot mode  (no flow control).

    Why in the normal boot mode the DSP remains "freezed"?

    Is the UART FAST NON flow control boot mode - a robust mechanism so I can really work with it without special concerns?

     

    Thanks,

    Ohad

  • 0 in reply to Ohad Shaked
    TI__Intellectual 2465 points

    Hi Ohad,

     I am in contact with design team on this. In the meanwhile I would advise you to try the following using UART boot mode w/o flow control :  

     

    - Disable CRC checking

    or

     

    - Slow down the sending rate, either by adding delay between all bytes or after each section load (with the delay amount proportional to the section length)

    If this will not work use the UART with flow control boot mode.

     

    Thanks and Regards,

    Majda