I am sure one of you has written a field updater that programs flash and my questions are probably very trivial to you... but I am totally desperate!
I am working on a field updater on c2808. Our application runs on flash. The board is connected to PC via USB serial convertor and read by MCU via SCIa.
The way it should work is:
1. Get command to enter update mode.
2. Copy flash API and update code to RAM
3. Start c2000 programmer on PC
4. Get program update via SCI
5. (this does not work yet…) copy data to correct locations
6. Restart (run usual boot, hopefully I did not change that code…)
I got through the autobaud, reading key value and reading the data from host.
Her are my problems.
i. addr 0 size 2
ii. addr 0x003FA000 size 2702
iii. addr 0x00000002 size 54
iv. addr 0x003FB128 size 276
v. addr 0x00000038 size 30
None of these are on Flash
Here is a clip from the map file
FLASHD 003e8000 00004000 000009d2 RWIX
FLASHC 003ec000 00004000 00003521 RWIX
FLASHA 003f4000 00003f80 00000347 RWIX
FLASHB 003f0000 00004000 00000000 RWIX
...AA 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3F 00 F6 7F 03 00 ..3E 00 A2 89 A9 28 02 03 06 00 ..66 00 3F 00 AC 42 FF FF 40 95 00 00 00 00 FE FF 42 95 00 00 00 00 00 00 ..FE FF 44 95 00 00 00 00 00 00 FE FF 36 95 00 00 1A F5 3E 00 FE FF 38 95 ..00 00 1A F5 3E
If this is size so what is size 00..? 0r address ..3E00A2?
Am I missing something (seems like a lot) ?any ideas and comments are VERY welcome
Thanks a lot for the help,
Oops, I see this comes up as a discussion, no idea how it happened and no idea how to change to a question…
5. (this does not work yet…) copy data to correct locations
did you try checking with codeskin team (C2000Prog) on why it doesn;t work for the device? if the device is supported or not? Did you try SDFlash?
if you don't want to use c2000prog, then you will have to build your own application try reading http://www.ti.com/litv/pdf/spraaq2 and apply it for your device as needed.The hex format you show above is the format that device bootROM expects the data to be in. On chip bootloaders only program RAM they don't program flash.
Thanks for your response.
I did contact Codeskin and waiting for reply from them.
Just to make it clear, I did not change the boot code that comes on chip. When I set GPIO34 to zero and start bootload it works fine (with the TI boot and c200prog). But I need a field updater and can not set GPIO34 to 0.
I am not sure I understand what you mean about the hex file.
I will try to use the SD flash, but is there code that works with it? What is it's protocol when transmitting to flash?
I think I understand now, you are trying to get data from c2000Prog (from PC) to device which is running your own update application. I was under the impression that you want to get C2000Prog working with ROM code on device.
neways, looks like the code in your map file is different from what your program (on device) decodes it to be after receiving the data from SCI via C2000Prog, right? Can you clarify and resend the details clearly of what your code decodes the map to be and what your memory map file says it to be?
I have done this before;
If you reconfigure the device back into the boot up state, drive GPIO34 low (as a digout) and jump to the start of the boot ROM, you can fool the ROM into SCI boot mode and then connect with C2prog.
The serial port need to be set back EXACTLY the same way as bootup or it will not work.
I recommend getting a copy of the source code for the boot ROM.
I think you are suggesting the best solution for me, but how do I jump back to boot code?
Also if I do this why do I need a copy of the boot ROM and in any case how can I get a copy of this code?
Thanks so much,
I tried a few things to go back to boot Rom.
First I set GPIO34 to zero in code: GpioDataRegs.GPBCLEAR.bit.GPIO34 = 1; (what does digout mean?)
Then I tried to cause SW reset by setting WD to zero:
I did this based on http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/21505/99477.aspx#99477 and http://www.ti.com/lit/ug/spru712g/spru712g.pdf but the MCU did not reset and also I am not sure doing this wouldn't Set GPIO34 back to 1.
I also tried to call the InitBoot but this will not pass linkage as the code is not part of my project.
What is the way to cause a jump to the InitBoot
I dont think the reset will work.
Drive GPIO34 low, then cleanup the SCI port to the same condition as boot. Then jump to the start of the Boot ROM.
The bootROM code should be in ControlSuite. The vector you need to jump to should be in there somewhere.
Just incase anyone looks at this and would like to know the "how to do" this.
It seems like the code to go back to bootloader should be:
const unsigned long int OperEntryPoint = (unsigned long int)0x3FFFC0; // Entry point address
and then to jump to the address:
((void (*)())(unsigned long)OperEntryPoint )(); // Calling to this as to a function...
But setting GPIO34 to zero this way does not work:
GpioDataRegs.GPBCLEAR.bit.GPIO34 = 1;
but if I set it by hardware it does work…
Make sure GPIO34 is configured as an output. Verifiy the pin gets pulled low.
The other trick is to make sure the UART is in the same condition as bootup, otherwise the SCIBOOT option wont work.
I did look at the code, it specifically programs the GPIO34 for input so if you configure the pin for output it will be reconfigured for input.
Also, SCI-A is initialized in SCI_Boot() so I don't think to re-initialize it first.
I wonder how you got it to work. It seems the only way is to bring out GPIO34 and bring it low (assumed normally pulled-up).
// Set DIR for BOOT SelectGpioCtrlRegs.GPADIR.bit.GPIO18 = 0;GpioCtrlRegs.GPADIR.bit.GPIO29 = 0;GpioCtrlRegs.GPBDIR.bit.GPIO34 = 0;
EDIS;// Form BootMode from BOOT select pinsBootMode = GpioDataRegs.GPADAT.bit.GPIO18 << 2;BootMode |= GpioDataRegs.GPADAT.bit.GPIO29 << 1;BootMode |= GpioDataRegs.GPBDAT.bit.GPIO34;
The boot ROM does as little as possible. The part boots up with the IO in the default configuration as from power-up.
It does not change this unless it needs too.
When working with the 2802x boot rom, I noticed that it does not change GPIO34 from the default (input).
So if you configure it as an output and drive it low (confirm this with a scope or something) and jump to the start of the boot ROM, it should select the SCI boot (provided the other pins are OK). BTW this will not work with a JTAG connected; you would need to set breakpoints and cheat the bootup sequence to get this to work.
If you can get the boot rom to run and select the SCI boot, you can then break in with a JTAG (hot plug) and using the ROM symbols, see where the programs is stuck.
The SCI will need to be configured in pristine power up condition (all REGs at power-up default) to get the baud rate to lock ect...
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.