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.
I have an application running on the TMS320F28034. Is it possible to jump to sci_boot() from the application using software?
Right now I jump to sci_boot loader by grounding the appropriate GPIO pin. I would like to do it in software if there is a way? If there isn't away then I will have to add a switch to my design to allow a user to update firmware. I really need this answered. I'm surprised no one has an answer to this question. It seems as though it would be a simple "No you can't" Yes you can here's a way.
Hi James,
Yes you can, here's a way :):
https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/244450/864118#pi316717=1
That thread should give you a decent idea on what you'd want to do.
Thank you,
Brett
Hi James,
I might recommend changing the clock/pll settings to how they would be if this code was being run from a cold boot.
Thank you,
Brett
I am not sure how to do that. What bits/registers would I set? The code I showed is the first thing to get executed in my app? Wouldn't the mean that all registers are default like they would be during a cold bootl?
Hi James,
Sorry, it was not abundantly clear that the code you specified was being called immediately after boot. In your case, therefore, nothing would need to be reinitialized.
After looking at this further, I do think you will need to call the SelectBootMode function prior to calling SCI_Boot(). Or better yet, I'd recommend adding some of the non-boot-mode-determination code in that function into your code. Some software in the SelectBootMode function does touch the clock settings and may affect the behavior of SCI_Boot.
Let me know if you stay stuck. If this happens, I'll need to loop in others.
Thank you,
Brett
Hi Brett,
I am still stuck on this. What I really want to do is skip having to change the state of pins to get to the bootloader. I just want to call the bootloader directly from software. By doing this I would avoid having to put any switches on my design. One thing to note is if I execute the code below using address 0x003ff7bf which is the address of InitBoot which calls SelectBootMode I am able to download using C2prog as long as I ground gpio 37. When I run the code below C2prog will actually block until I ground gpio 37 and then the download will proceed successfully. Is there a way in software to set gpio 37 low? If I could that it would solve everything. I did try to call SelectBootMode at address 0x003ff559 and the function didn't even wait. It just returned immediately. The first thing I tried was to call sci_boot at address 0x003ff6c7. C2prog gets past autobaud but then sci_boot returns before the download can begin. How can I call the boot loader from software without having to physically change the state of any pins?
unsigned long init_boot_addr = 0x003ff7bf; // init_boot
//unsigned long init_boot_addr = 0x003ff559; // SelectBootMode
//unsigned long init_boot_addr = 0x003ff6c7; // sci_boot
void (*entry)();
void main(void) {
unsigned long thisTimeStamp;
entry = (void(*)())(init_boot_addr);
entry();
James,
same is possible with 2803x, you should be able to put a HW break point, can you try to enable it from the dis-assembly window?
Best regards
Santosh Athuru
Hi Santosh,
I added symbols as you suggested. The symbols I load are the ones for the file I am trying to download.
this is the path and file name.
C:\Jason\CodeForJason\Firmware\GOI_ACIM\GOI_ACIM\GOI_ACIM.out
When I try to step into the call at address 0. The disassembly window shows "no debug contest", How can I step into the call at address 0 and debug?
The second thing I tried is to build the project at this path and debug
C:\ti\controlSUITE\device_support\f2802x\v230\f2802x_examples_structs\f28027_flash_kernel)
The first problem I encountered is that C2prog gave this error when I try and download
*** PLEASE RESET TARGET IN SCI BOOT-LOADER MODE ***
Connecting with target (autobaud)... OK.
Bootloading... failed (no response)!
So I did further debugging and found that this function doesn't echo anything back. Note that the echos are commented out.
Uint16 SCIA_GetOnlyWordData()
{
Uint16 wordData;
Uint16 byteData;
wordData = 0x0000;
byteData = 0x0000;
// Fetch the LSB and verify back to the host
while(SciaRegs.SCIRXST.bit.RXRDY != 1) { }
wordData = (Uint16)SciaRegs.SCIRXBUF.bit.RXDT;
//SciaRegs.SCITXBUF = wordData;
// Fetch the MSB and verify back to the host
while(SciaRegs.SCIRXST.bit.RXRDY != 1) { }
byteData = (Uint16)SciaRegs.SCIRXBUF.bit.RXDT;
//SciaRegs.SCITXBUF = byteData;
checksum += wordData + byteData;
// form the wordData from the MSB:LSB
wordData |= (byteData << 8);
return wordData;
}
Then I tried to put the echos in like so.
Uint16 SCIA_GetOnlyWordData()
{
Uint16 wordData;
Uint16 byteData;
wordData = 0x0000;
byteData = 0x0000;
// Fetch the LSB and verify back to the host
while(SciaRegs.SCIRXST.bit.RXRDY != 1) { }
wordData = (Uint16)SciaRegs.SCIRXBUF.bit.RXDT;
SciaRegs.SCITXBUF = wordData;
// Fetch the MSB and verify back to the host
while(SciaRegs.SCIRXST.bit.RXRDY != 1) { }
byteData = (Uint16)SciaRegs.SCIRXBUF.bit.RXDT;
SciaRegs.SCITXBUF = byteData;
checksum += wordData + byteData;
// form the wordData from the MSB:LSB
wordData |= (byteData << 8);
return wordData;
}
When I try and download using the above code C2Prog give me this error
*** PLEASE RESET TARGET IN SCI BOOT-LOADER MODE ***
Connecting with target (autobaud)... OK.
Bootloading... failed (invalid echo)!
C2prog sends a 170 and expects to get the 170 echo'ed back. Then it sends and 8 and expects to get that echo'ed back. The values are getting received correctly but C2prog doesn't seem to understand them when they get sent back. Do you know why this would be?
James,
from the source code comments, that example is supposed to work with serial loader utility, to get it working with C2Prog the SCIBOOT functions should be similar to what they were in boot ROM SCIBOOT.C file. Try to use SCIBOOT.C and SharedBoot.c from the boot ROM and see if that works.
Also refer to this app note.
http://www.ti.com/lit/an/sprabv4a/sprabv4a.pdf
on the first problem, I don;t understand the no debug context issue. If you have code loaded at 0x0, then you should be able to step through that code right?
Best Regards
Santosh Athuru
Hi Santosh,
I would actually like to focus on my application code posted below. The code below when I run it gives me the output from C2prog that I have posted below. It has acheived my first goal which is to call the boot loader stuff without having to change the state of pins. I would now like to write my own boot loader to do exactly what C2prog is doing. When I call sci_boot directly at address 0x003ff6c7 below C2prog give me the following output. The sci_boot code I'm able to debug and can see it loads the code into RAM.
Connecting with target (autobaud)... OK.
Bootloading... OK.
When I make the call to address 0. This allows C2prog to do the following
Connecting with target...
-Chip ID: 0xCF
-Chip Rev: 0x02
OK.
Unlocking target... OK.
Loading... OK.
Connecting with target...
-Flash API version: 200
OK.
Erasing flash... [ABC] OK.
Programming... OK.
I am going to get a serial port sniffer and figure out what the packets are that C2prog is sending to do the flash burn. Do you have a document that specifies these packets that
1. Read the chip id shown above.
2. Unlock the target shown above
3. Read the flash api version
4 Erase sectors [ABC}
6 Do the programming
unsigned long init_boot_addr = 0x003ff6c7; // sci_boot
typedef unsigned long Uint32;
typedef unsigned int Uint16;
Uint32 (*entry)();
void main(void) {
unsigned long thisTimeStamp;
entry = (Uint32(*)())(init_boot_addr);
init_boot_addr = entry();
entry = (Uint32(*)())(init_boot_addr);
init_boot_addr = entry();
*** PLEASE RESET TARGET IN SCI BOOT-LOADER MODE ***
Connecting with target (autobaud)... OK.
Bootloading... OK.
Please wait...
Connecting with target...
-Chip ID: 0xCF
-Chip Rev: 0x02
OK.
Unlocking target... OK.
Loading... OK.
Connecting with target...
-Flash API version: 200
OK.
Erasing flash... [ABC] OK.
Programming... OK.
Hi Santosh,
After sniffing the packets with a packet sniffer I can see that all SCI_Boot does is load a program and then jump to it.
It is this program that allows C2prog to output the following to do the burn (I guess it could be two programs. One to get the chip ID and rev and another to do the flash burn)
Connecting with target...
-Chip ID: 0xCF
-Chip Rev: 0x02
OK.
Unlocking target... OK.
Loading... OK.
Connecting with target...
-Flash API version: 200
OK.
Erasing flash... [ABC] OK.
Programming... OK.
Now the question becomes. What program? Since the output above reads a flash api version of 200. I wonder if the program C2 prog is loading the program at
C:\ti\controlSUITE\device_support\f2802x\v200\f2802x_examples\flash_f28027
in order to send the erase sector commands and program the flash. What program do you think C2prog is loading if it claims to be running -Flash API version: 200?
When I sniff the output during the programming phase of C2prog I can see the bytes from the intel hex record get programmed. For example
Output packet from C2prog captured with packet sniffer
00 3F 5F 57 A9 F1 0E E6 1E AC 56 63 00 A7 56 05
00 A7 56 8B A9 91 D0 0A 0E EE 1E AC 56 63 00 A7
56 05 00 A7 D5 A3 FC FF FE
I am able to match this data from the following line of the intel hex record for example.
<L1015>:205F5700A9F10EE61EAC566300A7560500A7568BA991D00A0EEE1EAC566300A7560500A753</L1015>
So what ever program C2prog is loading is excepting packets that take the following from
<32bit address><data><D5 A3 FC FF FE>
It seems that every packet that programs an intel hex record line has an FF FE on the end. It also has some other data between the <data> and <FF FE>
In the above would you be able to say what the D5 A3 FC is? Is it some type of check sum?
James,
I apologize, I cannot help with reverse engineering of C2Prog. Please take a look at the flash programming examples from ControlSuite for your device and flash programming kernels and with the guidance provided in this thread you should be able to come up with your own flash programming solution as you want to.
Also please check with C2Prog guys on the questions you have about their product.
Best Regards
Santosh Athuru
No Worries Santosh,
I think I get what I need to do now. I didn't realize that C2prog would be loading something non standard. I thought C2prog would be loading something from ti which is not proprietary.
I don't want to infringe on any copy right stuff for sure. I now plan to write my own flash loader based on the example you gave. I'll let you know if I have any question about that.
Hi Santosh,
I wrote my own host PC application to send an intel hex file to the code at
C:\ti\controlSUITE\device_support\f2802x\v230
I am running the code above without any changes in the ccs debugger.
It seems as though the file is being written to flash properly. Unfortunately it will not boot. Can you confirm that all I need to do is write the hex file and entry point and the code should run? Is there any else I need to write to get the code to boot? I've tried two different entry points.
this one from my map file
OUTPUT FILE NAME: <GOI_ACIM.out>
ENTRY POINT SYMBOL: "_c_int00" address: 003f5813
I also tried the address of main.
0 003f413b _main
Which one should I be using?
Can you think of any reason why the code will not run after it has been programmed.?
James,
for boot to flash to work, the entry point should be at BOOT TO FLASH entry point as mentioned in the boot ROM chapter of TRM.
You can program the same COFF file from CCS and compare the Flash contents between CCS programming and your boot loader programming.
Hope this helps.
best Regards
Santosh Athuru