• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 1234 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.

'5509A boot problem

Bill Allen
Prodigy 230 points

Hi,

I'm using a '5509A, and booting from a 24-bit address serial flash. Everything works fine - the DSP loads the boot table (verified on a logic analyzer) and GPIO4 goes high, indicating it has finished. Then....nothing. The code works fine when loaded from the JTAG debugger, though.

I have verified the correct starting address (from the .map file) and all reg_config options are correct (there's only one to set the clkmod register). This option works fine, as you can see the delay and clock change.

There are no gel files in the project, so that's not the issue.

In an effort to track this down, and remove anything related to DSP/BIOS, my main() simply sets XF low (it defaults to high) and then goes into an endless for() loop, but it never gets there. All interrupts are disabled, as well.

In SPRA375F, there is a section on debugging bootloader issues, which I have tried to get through, but there is a fundamental problem with one of the suggestions. It suggests using a JTAG debugger to verify the code hits a breakpoint at the starting address. However, I have yet to figure out how to use the debugger with code loaded from an external source. You can't 'connect' to the target if it's in reset, but releasing reset causes the DSP to boot from the serial flash and, at least in my case, the debugger can't connect once it's started and /or finished the boot process.

Any ideas?

Thanks, Bill

  • 0
    TI__Genius 13045 points

    Bill,
    Hard to say what is going on here.  From you description it sounds like you are doing everything correct, but something must be going wrong.  This is a commonly used boot mode and we know it works.

    What version of CCS are you using and what JTAG emulator?  You should be able to connect to the target after it has started running if it is in a normal state.  What exactly happens when you try to connect to the target board with CCS?  Do you get error message?  What is different on connecting after boot compared to when you use CCS to download code?  Both require connection to the target.  So if one works, so should the other.

    You say you can see the clock change as a result of the clkmode change.  Are you monitoring CLKOUT?  It is still active after the boot is completed?

    What commands do you use to create your boot table with hex55 utility?  I am wondering if something is wrong with the boot table.  Did you check the boot table to make sure it had the correct entry point as described in 4th step in the debug suggestions (sec 3.5).  This is the same step that suggests trying to connect with the JTAG emulator.

    Regards.

     

  • 0 in reply to TommyG
    Prodigy 230 points

    Tommy,

    I am using CCS 3.3 with the XDS510 USB JTAG. I have CCS 4.1.1, but I don't like changing things in the middle of a project (been burned too many times).

    You are correct in that after the bootload, when I try to connect, I get error message  0x80000244/-1143, stating that memory at 0x00000000 continually indicated it was 'not ready'. The message goes on to say that this is considered a fatal error and the processor should be reset.

    I can run the code via the emulator by changing the boot mode (via jumpers) to one that is not implemented, and the emulator connects just fine.

    As for the clock change, I can see the SPI clock frequency change after setting the clkmod register. CLKOUT is active during the boot process, but then stops when the bootload is complete.

    I've also double checked that I am not using DARAM below 0x00200, as per information in SPRA375F, and this is verified in the .map file.

    This is my command line for hex55:

    -boot -v5510:2 -serial8 -reg_config 0x1c00,0x2812 -delay 0xffff -b -o nanoDL.bin nanoDL.out

    Thanks,

    Bill

  • 0 in reply to Bill Allen
    TI__Genius 13045 points

    Bill,

    I'm going to have to check on the error message meaning.  However, I don't know why the emulator would be trying to access address 0x00000000.  That should be the memory mapped register bank.  Are you sure you don' t have a gel file active?  Would it be possible to see your .map file?

    The fact that CLKOUT stops when bootload completes could mean that the device has locked up somehow.  Does your code disable CLKOUT?

    Regards.

  • 0 in reply to TommyG
    Prodigy 230 points

    Tommy,

    I was incorrect; there is a gel file in the project. I just wasn't aware that they only show up if the JTAG is connected to the host.

    The gel file is the generic one included in CCS for the 5509A. Other than the hole below 0x200 I created for the bootloader, I've followed the default memory map, so it really doesn't explain why things are going out to lunch. Or, maybe I'm missing something fundamental.

    I'd be happy to attach the map file, but it's a bit large to just paste it into the post. Anyway I can email it?

    Thanks, Bill

  • 0 in reply to TommyG
    Prodigy 230 points

    One more thing - CLKOUT runs for about 5mS out of reset at the crystal freq. (12 MHz). GPIO4 stays low for about 450mS, so I think CLKOUT is going away when I configure CLKMOD at the begining of bootload. Not sure why this would be though.

    Bill

  • 0 in reply to Bill Allen
    TI__Guru*** 125430 points

    Simplify wherever possible to get to something that works.  For example, make your application a simple while(1) loop and nothing more.  Get rid of bootloader commands to change clock frequencies, etc.  Use only internal RAM.

  • 0 in reply to TommyG
    Prodigy 230 points

    Tommy, Brad,

    I got it going. It turned out to be an external SRAM that DSP/BIOS was trying to initialize. Since there was nothing mapped to it, or loaded into it, I wasn't aware that something would try to access it before my code had a chance to initialize the EMIF for it. I am assuming that since it was in the DSP/BIOS memory configuration, it was trying to do something with it. When I completely removed it from the configuration, things worked.

    I'll add the EMIF configuration for the SRAM to the hex55 cmd file and go from there.

    Thanks for your help,

    Bill

  • 0 in reply to Bill Allen
    Prodigy 245 points

    Bill, 

    i think i have a similar / the same problem. 

    I downloaded a bootloader-file (*.bin) to the NAND-flash of my board by "programmer.out".

    Since this time i get the following error when i try to connect to the board (C5515 EVM): 

     

     

    Error connecting to the target:

    Error 0x80000244/-1143

    Fatal Error during: Register, Initialization, OCS, 

    The memory at 0x00000000 continually indicated it was 'not ready'

    All memory operations currently in progress were aborted in order

    to regain control of the processor.

    This is considered a catastrophic event, but the debugger should 

    still be able to access memory and CPU registers.

    System state has been altered.  It is strongly advised

    that the processor should be reset before resuming execution,

     

    I am not able to send an other boot file (created with hex55) to the board. 

    Is there a possibility to delete the boot-file from the NAND-flash?

    You said, you removed the SRAM from your configuration - how did you do this?

     

    Thanks for your help

    Martin

     

  • 0 in reply to Martin S.
    Prodigy 245 points

    Bill,

    now i made it to send an other boot file.

    I do net get an error if i connect to the board.

     

    But the problem with the SRAM is still the same. How did you solve this problem? Do i have to delete the SRAM in the Configuration Tool - Memory Section Manager? How did you include the EMIF in the hex55 cmd file?

     

    Thanks for your help

    Martin

     

     

  • 0 in reply to Martin S.
    TI__Genius 14965 points

    Hi,

     

    You can include any register control in the hex55 cmd as described in the http://focus.ti.com/lit/an/spra375f/spra375f.pdf section 2.5.3.

    The usage is as following:

    -reg_config 0x1C00, 0x0000;    write 0000h to port address 1C00h

     

    Regards,

    Hyun

  • 0 in reply to Hyun Kim
    Prodigy 245 points

    Hi,

    my problem is the following:

    If i create a heap in my SRAM (of C5515 EVM) the bootloader goes wrong.

     

    Do i have to create the heap in the code and not in the DSP/BIOS (if yes - how can i do this)?

    Bill said he added the EMIF configuration for the SRAM to the hex55 cmd file. What configuration does he mean? 

     

    Regards,

    Martin