Forums

Yona Cohen

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.

Best Regards

Santosh

 Hi Santosh

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?

Thanks again,

Bets regards,

Yona

Yona,

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?

Best Regards

santosh

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,

Yona

Hi Jason,

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

Thanks

Yona

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. 

Jason,

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 Select
GpioCtrlRegs.GPADIR.bit.GPIO18 = 0;
GpioCtrlRegs.GPADIR.bit.GPIO29 = 0;
GpioCtrlRegs.GPBDIR.bit.GPIO34 = 0;

EDIS;
// Form BootMode from BOOT select pins
BootMode = GpioDataRegs.GPADAT.bit.GPIO18 << 2;
BootMode |= GpioDataRegs.GPADAT.bit.GPIO29 << 1;
BootMode |= GpioDataRegs.GPBDAT.bit.GPIO34;

Tuan,

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...