Is there a concerto bootROM Api library published?

Larry,

we don't have a ROM API library published yet, this is under discussions. TI will release ROM API symbol library for cusotmers to include in the apps for linking functions to ROM.

The below should be possible, I haven't tested this yet but there is no reason it shouldn't work. I can give you the needed details, let me know if it works.

From you applicaiton you should call below functions, in the order shown. I have given the address for the funcitons in ROM.

void ConfigureDevice(void) => 0x01003b89

void PickInterface(void) => 0x01002b49

void Update(void) => 0x01000861

call_in_below_order()

{

ConfigureDevice();

PickInterface();

Update();

}

make sure you set the NVIC table base to 0x00000000 before you call back to ROM loaders because the UART loader needs GPIO interrupt handler for AutoBaud detection. For more information on M-Boot loaders, please refer to Boot ROM chanpter of device TRM.

Best Regards

santosh

Hi Santosh,

Thanks for the quick response.  I would like to try this, would you suggest that I call those routines by casting those addresses to functions returning void, with void arguments?  Also I posted another question, if I can sneak it in - can UART0 use alternative modes, e.g. mode 13 instead of 1 ?

Thanks,

Larry

Hi Santosh,

How I envision using this is that the user is connected through the front usb on the Concerto board, which goes to the front panel of the case. I've ported the usb_dev_serial demo using UART0 mode 1, and we're displaying a serial menu to the user's terraterm window. The user is using either a usb serial converter or something like MWare/windows_drivers/usb_dev_serial.inf  They choose "download" and that calls the download() routine, it writes 0 to the NVIC table base, then calls

ConfigureDevice();

PickInterface();

Update();

Is Update collecting packets, i.e. calling ReceivePacket(), and acking or naking?

How will I know I'm done, is there a flag I can check, or a total size I can monitor?

In this case I'll be running the usb_dev_serial protocol layer, but it won't be there when we've rebooted to serial bootloader, is there any support for that in the boot rom?

Thanks very much,

Larry

Hi Larry,

Larry Ansell said:

Is Update collecting packets, i.e. calling ReceivePacket(), and acking or naking?

yes, section 6.5.14.1 of TRM explains this. more specifically 6.5.14.1.4 gives what you need. On Host I beleive you can use LM Flash programmer utility for your test, it can send data over USB serial interface to the device.

Larry Ansell said:

How will I know I'm done, is there a flag I can check, or a total size I can monitor?

In this case I'll be running the usb_dev_serial protocol layer, but it won't be there when we've rebooted to serial bootloader, is there any support for that in the boot rom?

After you send the last data packet, you will have to issue a RUN command or RESTART command to start the applciation. As soon as you receive an ACK for that command you know the applciation is running.

Best Regards

Santosh

Hi Santosh,

Q1) I'm confused about what code I need to write, what code is already there.  Update() implements 6.5.14.1.4, is that right?

Once an interface is picked to boot, Update() function is called which sits in an endless loop accepting
commands and updating the application code when requested. All transmissions from this main routine
use the packet handler functions (SendPacket(), ReceivePacket(), AckPacket(), and NakPacket()). Once
the update is complete, the application can be started by issuing a COMMAND_RUN command or
COMMAND_RESET command.

Q2) If Update is doing the ReceivePacket(), how does my code know that a new packet was received, acked?

Q3) My code presumably sends at the beginning a COMMAND_DOWNLOAD, and then a COMMAND_SEND_DATA for each packet we've received, and that data gets burned into flash?

Q4) Is there any support for serial USB in the bootloader?

Thanks again,

Larry

Larry,

nope we dont have support for usb serial boot in ROM.

yes the update() function in ROM takes care of all of that, your code will have no control over it when calling the update() function. Also note that ROM loaders doesn;t support flash programming. I believe in your case you would want to flash the data after receving each packet. Also you want to use your own usb serial driver interface to get the boot data.

Lets take a step by step approach. First lets try getting app working by using basic UART interface that boot ROM supports natively.

NOTE: Also remember not to touch Boot ROM reserved RAM when you want to call back the ROM loaders/functions, because they are linked to work with data in this RAM.

1.> your application will call

ConfigureDevice();

PickInterface();

Update();

Now, when your HOST completes the SEND_DATA command, it can use COMMAND_RUN with address of the function in your application and the update() function in ROM will branch to that function address after you are done flashing that data you will repeat the above step. in short here you are using update() function to receive data.

Once you have above frame work running, (because I'm sure we might run into some issues regarding stack  usage, RAM usage - where your applciation resides where the incoming data should be loaded to ..etc etc,), you can worry about how to hook up your own usb_serial send_receive functions and still use the ROM update function. The way I think it should be possible is as below.

ConfigureDevice() - configures the peripheral and IOs - your application should do this, when using usb_serial

PickInterface(); - hooks up the send, receive and flush funcitons to function pointers used by update() function. Your application should do this ( I can give the information on these function pointer locations used by ROM)

Update() - This function uses the send/receive/flush functions hooked up in prev. step to receive the data.

Please let me know if above makes sense for you, you might end up saying implementing whole thing in application is much cleaner and easier. But above should be possible and provides the benifit of data transfer taken care by ROM functions.

Best Regards

Santosh

Hi Santosh,

Thanks for your answers and continued patience! 

In this baby example, we've done the calls from 1.> above, the host sends serial data which is received by Update(). I assume that my application gets control after Update() receives a packet?  And that it's the application that sends COMMAND_RUN to the Update() with the address of my flashburning() routine?  When my flashburning() routine returns, does it return to the calling context of Update()? Or do I explicitly call Update() again to repeat the receive and burn cycle?

I agree that the advantage of reusing the bootROM functions is that I can leverage already written, debugged, and working code,

Thanks again,

Larry

Larry,

Larry Ansell said:

When my flashburning() routine returns, does it return to the calling context of Update()? Or do I explicitly call Update() again to repeat the receive and burn cycle?

when the flashburning() completes, it shouldn't return back to update(), we don;t want that. Because the proceedure that update() follows when it gives control to flashburning() after recieving a packet and copying it to RAM is

> disable all peripherals

> reset all peripherals

> disable and clear any pending interrupts

remember, for update() funciton, it thinks that it is calling an application when serving the COMMAND_RUN. so after your flashburning() returns, you will have to follow the proceedure again for the next packet.

ConfigureDevice();

PickInterface();

Update();

if you get it working for one COMMAND_DOWNLOAD, COMMAND_SEND and COMMAND_RUN sequence, you can expand it further to DOWNLOAD, SEND, SEND, SEND, RUN...

Best Regards

santosh

Hi Santosh,

Thanks for all the answers!  In my original scenario, using the front panel usb, I realized that I don't know how to connect the USB to the usb_dev_serial protocol that talks to the uart. Do I for example just need to go into the usb_dev_serial.c file and change UART instances to the UART that I want to use?

The hardware has put the USB on pins:

PF6_GPIO38 has USB0VBUS, PG2_GPIO42 has USB0DM, PG5_GPIO45 has USB0DP, PG6_GPIO46 has USB0ID, PJ1_GPIO57 has USB0PFLT, PC5_GPIO69 has USB0OPEN

Thanks again for your help.

Larry

Larry,

if i understand your question, the hardware uses different set of USB pins and the provided example uses a different set? then just change the SW example to the pins you use.

Best Regards

Santosh

Hi Santosh,

Thanks very much for the quick response.  In the usb_dev_serial.c example code, they use the first 4 of the hardware connections that I worried about,  so I do see I could change those (DUH), but what about the 2 that aren't set up here, do you know where the PortJ PFLTand the PortC OPEN are specified?

Thanks,

Larry

Hi Santosh,

I'm going to try this in the next day or so, I need to get the usb serial working first.  I also need to have the download serial stream to send with the correct protocol in accord with 6.5.14.1.4.    First the serial stream will send the COMMAND_DOWNLOAD Question, does this command really erase the flash? and pend for the ACK/NAK.  Then do I want to send COMMAND_SEND_DATA (bearing in mind that it doesn't really burn flash? ) Then the data bytes in packets in accord with 6.5.14.1.4. Then COMMAND_RUN the flashBurner.

The application is invoked, it tells the user to start sending the download serial stream

Writes 0 to the NVIC table base, then calls in a loop

STARTLOOP

ConfigureDevice();

PickInterface(); 

You mentioned that it "hooks up the send, receive and flush funcitons to function pointers used by update() function. Your application should do this ( I can   give information on these function pointer locations used by ROM)"  So I need help with this please.

Update();

Update() gets the COMMAND_RUN, has jumped to flashBurner()

flashBurner() code

ENDLOOP

Will this work like I think it will?

Thanks,

Larry

Larry,

regarding usb serial interface help, please open a new thread. Trey might be able to help you get that to working quicker.

Regarding the above sequence, what I said was first lets get it to working using native UART to flush out any unknowns and build confidence on the method. after you get it to working with UART we can worry about hooking up USB-SERIAL interface.

Best Regards

Santosh

Hi Santosh,

Agree, this will be just native UART.  So when I have the GPIO mode switches set to serial, and cycle power, the bootROM will end up running in Update() waiting for serial traffic over UART0.  I will have to use it to get my flashBurner() code into ram.  So do I want to send COMMAND_DOWNLOAD (it presumably doesn't erase the flash) followed by COMMAND_SEND_DATA's which won't write the flash?  Is it correct that I'll end up with a RAM image that I'll be able to COMMAND_RUN (or COMMAND_RESET) to run the flashBurner()?

Thanks for all your help,

Larry

Larry

the ROM loaders doesn;t support flash programming or erasing. They just load code/data to RAM - I beleive there are errors in TRM regarding that. we are getting those corrected.

if you set the device to serial boot mode, yes you will have to follow DOWNLOAD, SEND, SEND...RUN/RESET. The RESET command will start the applicaiton where the last DOWNLOAD began. The RUN command will get the application start address from the command itself. So you would be using RUN command by pointing it to the flashBurner() function address in RAM if that works and if thats what you want.

For your case, to begin with, have CCS load your application that has flashBurner() function. In your application you will have to call back to ROM functions as mentioned in few posts above and the RUN command will branch back to your applciation at flashBurner. Now the flashBurner function will know where you have donwloaded the data and how much data is available and where it has to be programmed in flash.

Best Regards

Santosh

Hi Santosh,

One more question please, does LM Flash Programmer implement the serial protocol DOWNLOAD, SEND, SEND, RESET when one uses the serial download of a binary image?  So I could use it to load the flashburner to RAM and run it, is that right?

Thanks for all your help,

Larry 

yes, LM Flash programmer does support that.

I'm not sure if it supports DOWNLOAD, SEND, SEND, SEND....RUN though.

Best Regards

Santosh

Mark for studying