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.
hallo,
I would like to load my flash from eCAN, but after that boot every time from flash.
if I understand correctly, when setting the OTP BMODE to eCAN, it's a one time programming, so I would always jump to the eCAN (since i'm using the GetMode at power up).
how can that be done ? I only want to update my software through eCAN and then return to boot from flash.
if it's possible can you post some example (I assume the .cmd file needs to be changed etc)
thanks a lot
Ari.
Hi Ari
The best possible solution here has to come from the application running in flash.
Set your device to boot to flash, always and whenever your application has to update itself then call the CAN boot functions to get the data to update application image in flash. You will have to design your application in flash properly to do this though.
Best Regards
Santosh
Dear Santosh Athuru,
Do you have an example of such application?
Thanks,
A.T.
Santosh Athuru said:Hi Ari
The best possible solution here has to come from the application running in flash.
Set your device to boot to flash, always and whenever your application has to update itself then call the CAN boot functions to get the data to update application image in flash. You will have to design your application in flash properly to do this though.
Best Regards
Santosh
A.T,
we don't have a straight one stop example for this. I beleive there is enough collateral provided in controlSuite to get this done.
> Boot ROM sources are provided, you can load bootROM COFF symbols and see how CAN BOOT mode works and you are free to either call back ROM functions or put similar functions in your application.
> You can start with any application that can run from flash and read a GPIO. If GPIO is SET -> do firmware upgrate and if not then start the existing application in flash. Here I have specified GPIO usage as an example you can use any other indication that fits the application design to help the code decide wheter to do firmware upgrade or not.
> if code decides to upgrade itself then it has to copy a part of itself to RAM and execute from RAM while it receives data from CAN and programs flash with the new data.
Please let us know if you have any questions. Basically what you are trying to do is build your own flash based loader, I will check with Trey if he has any other ideas/suggestions and if he has I will request him to throw some more light on this.
Best Regards
Santosh
Dear Santosh,
Thanks allot for your quick reply.
The hardware is in a closed box so configuring and then reading an I/O is not possible.
I thought of the following design option:
Upon receiving a command from host, write some signature to a specific flash location that tells the firmware that it is in SCI BOOT mode.
Then, "jump" to the device SCI BOOT code and use a commercial tool like C2Prog to reprogram the device via UART (SCI).
How do I jump to the SCI BOOT code?
Where is it located in ROM?
Will it work without configuring the I/O to SCI-BOOT?
Thanks,
A.T.
A.T,
you can find the beow details in controlSuite source folders, for 2803x devices I have boot ROM at this location "C:\ti\controlSUITE\libs\utilities\boot_rom\2803x\2803x_boot_rom_v1\source" . You don't have to recompile bootROM. The C:\ti\controlSUITE\libs\utilities\boot_rom\2803x\2803x_boot_rom_v1\Release\2803x_boot_rom.map file has the symbol addresses in ROM. take a look at SCI_Boot.c file it has the function that starts SCI loader. If your SCI GPIO pins are same between board design and bootROM usage then you don;t have to configure any IOs but just simply do a function call to SCI_Boot function in ROM.
Avi Tal said:How do I jump to the SCI BOOT code?
Where is it located in ROM?
Will it work without configuring the I/O to SCI-BOOT?
Best Regards
Santosh
Dear Santosh,
Thanks again for your reply.
From the map file you pointed me to, the SCI_Boot code is located at 0x003FF7DD.
So my code makes a call to this address by the following operations which seem to work correctly:
unsigned long boot_addr = 0x003ff7dd;
void (*entry)();
entry = (void(*)())(boot_addr);
entry();
And the code branches there.
But, I am unable to communicate with the SCI Boot like I do when configuring dip switches.
What am I missing?
Thanks,
A.T.
you can add bootROM symbols after you load the application and step through the SCI Boot code, it will tell you what might be wrong.
choose "add symbols" from the CCS menu options and choose bootROM COFF file and then locate sources to boot ROM sources directory. You need to add bootROM symbols after you load your application.
Avi Tal said:What am I missing?
regarding above, " entry = (void(*)())(boot_addr);" is this the first thing you do in the application? are you disabling watchdog before branching back to bootROM, ROM handlers doesn't service watchdog - so watchDOG should be disabled. Are you configuring the SCI boot mode IO pins to something else?
loading ROM symbols and stepping through the code will help you understand the code better. Eventually if it works then you can use ROM API Symbols library to link to SCI_Boot function in your application without the need for hardcoding the ROM symbol address.
Best Regards
santosh
A.T.,
Woah, when did the SCI boot mode come into play?!? I thought we were trying to flash the device via CAN???
Santosh is correct that you need a flash bootloader. The bootloader will sit in one sector of the device and will always be executed first. The device will boot this code and this code will make the decision as to whether an update is needed or not. If it isn't, then the bootloader will simply boot the application already programmed in flash. If an update is needed the bootloader will configure CAN and recieve and flash the new firmware. You could also put hook in your bootloader such that the application could call back the bootloader should the application need to be updated after it has already been bootloaded.
All that being said, bootloaders are typically very complex pieces of software that are very fine tuned to end applications. Many companies specialize specifically in bootloader design, so architecting a bootloader in a forum thread really isn't the way to go. I recommend you go do some research on flash bootloaders and how they are typically architected. Then after you come up with a design, I would be happy to take a look and give you some feedback.
Regards,
Trey
Hi Trey,
Thanks allot for your reply.
Although this post was originally opened by someone else as a CAN boot, I actually need an SCI boot.
I have designed and implemented various boot loaders on other devices (mainly DSPs). I am new to Piccolo, so I have to start somewhere...
My current thoughts are to brance to the SCI_Boot function in ROM and then program the device like I do when it originally booted from SCI.
I hope this will work.
Please tell me if you see any problems with this path.
Thanks,
A.T.
AT,
Ahh, I was confused...
You should be able to call the SCI_Boot functions, I'm just worried about actually flashing the code. The SCI boot modes really only load code into RAM, after you give execution to these functions you'll need a way to regain control of execution and burn the code that has been loaded into RAM into flash. I'm not super familair with the pre-existing bootmode functions, but if you can some way make use of them it will reduce your bootloader code size.
Trey
Trey,
A.T. wants to call back to SCIBOOT and let C2PROG/SDFlash on host handle the flash update on device from there on. I think it should be possible because C2PROG tool running on host allows do program flash on device using SCI boot mode.
if C2Prog is not used on host to take care of this, then we will have to worry about how to get the data to flash from RAM or from peripheral. This is taken care of here by C2Prog atleast to start with.
Best Regards
Santosh
Hi Trey and Santosh,
I tried to call back to SCIBOOT and let C2PROG on host handle the flash update on device from there on like Santosh mentioned, but it did not work.
I started to debug the SCIBOOT code in ROM, but appearently the symbols in the sci_boot only show assembly.
The CPU is traveling somewhere inside the SCIBOOT code.
All interrupts are disabled before the call.
Any sugestions?
I also tried to rebuild the 2803x boot rom project but when loading the project, some libraries such as Flash2803x_API_V100.lib are not found.
Do you know where it is?
Thanks,
A.T.
A.T
Does C2Prog work with the device when you boot the device to SCI BOOT mode on power up? I mena if you have ever for C2Prog to work with the device and set up before?
you will not be able to rebuild the boot ROM project, it is not provided for that purpose. You will hae to use the already available MAP and COFF files.
Can you explain what you mean by 'it did not work"? the autobaud doesn't lock or C2Prog is throwing an error or ???
Best Regards
Santosh
Dear Santosh,
When the device is configured to SCI BOOT mode on power up, C2Prog works fine.
When I mentioned that it did not work, I meant that the autobaud doesn't lock.
Any Idea?
Thanks,
A.T.
A.T,
in your application code can you make sure that you are able to use SCI at all? put a test function (loopback) in place where you branch to ROM and see if that works.
mostly it might not be working because you are missing some initialization. You said you are disabling watchDOG before you call back into ROM right?
Best Regards
santosh
HI,all
I use Flash2803x_API_V100_CCS3.3v examlpe to program OTP_KEY(Address 0x3D7BFE) and OTP_BMODE(Address 0x3D7BFF) in Example_Flash28035_API.c ,
the step is
//////////////////////////////////////////////////////////////////////////////////////
// Example: This will return an error!! The location specified
// is outside of the Flash and OTP!
//Flash_ptr = (Uint16 *)0x00340000;
//OTP
Flash_ptr = (Uint16 *) 0x3D7BFE;
Length = 2;
Status = Flash_Program(Flash_ptr,OTP_DATA,Length,&FlashStatus);//here OTP_DATA[2]={0x55AA,0x0007};
// This should return a STATUS_FAIL_ADDR_INVALID error
if(Status != STATUS_FAIL_ADDR_INVALID)
{
Example_Error(Status);
}
my question is , I must to loader code from CAN bus every time when I power up,The 28035 can't boot from it's flash now.
How can I do? And I need the eCAN bootloader yet.
Thank!
Miguel,
You should only program the OTP boot mode values once your application is fully developed and ready for deployment. In the interim you should be using the EMU boot mode values which are in RAM and can be reprogrammed.
You can get the device to boot to flash by reprogramming the OTP_BMODE to an invalid value. Please read the bootROM reference guide for this part (page 16 to be specific).
We do not supply flash CAN bootloaders. There are numerous 3rd parties which provide these. If you are looking for a low cost CAN bootloader for C2000 devices, I would recommend you look at what www.simmasoftware.com has to offer.
Trey
Hello Trey,
Thanks for reply me so quick.
Many DSP28035 boards will be work in the machine and they communicate each other with CAN.
What I want to do is: I want to update the firmware through CAN( no just one times ) when my DSP28035 boards work in machine. If update through CAN succeed,DSP28035 will running new firmware every time after power up.(I want they boot from Flash with the same firmware every time after they boot through CAN).
my question is : I update firmware through CAN succeed( OTP_BMODE is 0x0007) and the true is they work with the new firmware,But when power down then power up, they don't running with the new firmware ,and they wait to be boot through CAN once again. So the integrated CAN boot is no suit for me to update new firmware in field application ?
And I must to write CAN boot firmware by myself ?
Sorry I'm poor in English.
Thanks.
Miguel,
Ok, I understand what you are trying to do. What you need is a CAN bootloader.
Right now you are using the CAN boot mode. This boot mode is used to load code into RAM for execution. Since the code is in RAM, when the device is powered down the application will be lost. This is not what you want.
A CAN bootloader is a small helper application that you will program into flash and will be used to update your main application. The bootloader will contain all the software needed to update your application including the flash programming routines.
We do not supply CAN bootloaders, but numerous other 3rd parties do. If you are experienced writing embedded software, you could certainly write your own bootloader. However, you may be better off purchasing a bootloader from a 3rd party who is an expert on them. I would highly recommend you take a look at Simma Software. Their software is very competitively priced and has a very small memory footprint.
Trey