• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 83 subscribers
  • Views 3865 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28035 SCI Bootloader Problem

Jeff61040
Intellectual 270 points
Other Parts Discussed in Thread: TMS320F28035

Hi there,

I've written a bootloader tool for loading code onto a TMS320F28035 over the SCI interface, but something doesn't seem to be working. I am using the following steps:

1.) Build the application, running hex2000 <.out file> -boot -sci8 -a

2.) Load the firmware file into my bootloader.

3.) Autobaud with an 'A' character, waiting for the part to respond with an 'A'.

4.) Send each hex byte from the file sequentially.

5.) Cycle power, changing the bootmode pins to GetMode.

The issue I'm seeing is that everything appears to work - I get an autobaud response and I can confirm that the part is echoing back all the bytes I'm sending it (without any errors) - but as soon as I boot it from flash, it's clear that the code is the same as before bootloading. I have confirmed that the CSM is not active, so that shouldn't be an issue. Any ideas what's going on here?

  • 0
    Mastermind 7585 points

    Jeff,

    in your procedure I cannot see the step where you actually call the FLASH - API functions to reprogram the FLASH (between step 4 and 5). After sending the hex-bytes to the RAM of the device you will have to call the FLASH - erase / program APIs. If your load sequence covers a larger amount of bytes, you may have to split that procedure in multiple parts.

  • 0 in reply to Frank Bormann
    Intellectual 270 points

    Hi Frank,

    Sorry about that - I should've been a bit more specific: I'm just using the SCI boot ROM. I understand that the FLASH API lives in the boot ROM as well for the Piccolo MCUs, which I assumed meant that the factory bootloader used it - is this not the case? In other words, do I need to load a FLASH API based bootloader application into RAM before loading my application?

    Thanks for your help,

    Jeff.

  • 0 in reply to Jeff61040
    Mastermind 7585 points

    Jeff,

    as far as I know the FLASH API is stored in ROM but it is not used in the SCI bootloader sequence. What you can do, if your new binary sequence fits into the RAM as a whole block, you can start a code sequence from the RAM entry point and call the ROM - API functions.  At the end, you can branch into the new code. I did this in the past with the APIs as part of the download stream, but it should also work with the ROM-APIs.

    Regards

     

     

  • 0 in reply to Frank Bormann
    Intellectual 270 points

    Frank,

    Thanks for clearing this up for me. I ended up writing a small RAM-based application to allow a GUI application to interface with the flash API via RS-232 and it works great.

    Thanks again,

    Jeff.

  • 0 in reply to Jeff61040
    Prodigy 20 points

    Should be between steps 4 and 5 an autobaud data exchange, or after transferring bootloader the Flash API is callable immediately?

    I don't get any feedback from MCU after transferring the algo file FlashAPIInterface2803xV1_00.out to F28035. But the algo transfer works fine.

    What is wrong?

  • 0 in reply to Karim Baban
    Mastermind 7585 points

    Therei is no need for another autobaud detection, once the download is done.

  • 0 in reply to Frank Bormann
    Prodigy 20 points

    Thanks for your reply, Frank!

    After loading the Flash API interface over SCI to MCU, I get no answer, no matter what I send to.

    I'm trying to send the message header at first (8 bytes) and then the flash command (20 bytes). The MCU is silent.

    What am I doing wrong?

  • 0 in reply to Karim Baban
    Mastermind 7585 points

    It is difficult to say from here, what is going wrong in your code. I would recommend to split the problem. First I would try to setup a project, in which you use the SCI-bootloader to download and start code, which is not using the FLASH-API at all. If this works, then you can try incorporate FLASH-API's in  a RAM based project. If this also work, then you can merge project1 and 2.