Bootloader via SCI

Wail,

Can you please specify which source files you find the GetMode() function in ?

Thanks

Noah

Wail,

there is no difference, SCIBOOT using GPIOs and using Software GetMode() behaves the same, as shown in figure2.5 in the TRM for TMS320F28069.

Please refer to TRM : http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spruh18b&fileType=pdf

Best Regards

Santosh

Hallo Noah,

Thanks for your reply.

Sorry but. I have doubt about your question. I think I did not understand it perfectly.

I have only assessed " spruh18b.pdf ", chapter 2. It is my source of information.

I am interested in more detailed block diagrams and information about " stream of data "

Please, take a look in my talking with Santosh

Thanks again !!!

Wail

Hallo Santosh,

Thanks for your reply.

I have already assessed the document suggested by you and I would like to mention the figure 2.9.

In this figure we can conclude that Get_mode() Function makes use of both OTP Register (OTP_KEY and OTP_BMODE) to select the Boot Mode.

However, in the figure 2.8 we can conclude that a selection via GPIO pins will also check all other modes intead to go directly to desired mode e.g.

 SCI - GPIO37=0: GPIO34=1 or Paralel - GPIO37=0: GPIO34=0 

It seems a little bit ambiguous !!!

This diagram seems more confused when we try to relate it with tables 2.7 and 2.8. The flux of information does not look clear.

Summarizing, could I affirm that the following sequence is correct ? ( or not ? )

Set by hardware TRST=0: GPIO37=0: GPIO34=1 - SCI
Force a hardware RESET
Send an stream of data with the same structure of the table 2.10
After conclude the transference, the program will start imediately from Entry Point

Thanks a lot for all your attention

Wail

Hallo Santosh,

Thanks a lot for your detailed answer !!!

When you mention "EMULATION"  the panorama changes for me. I do not have knowledge about it

Perhaps, I could go more in depth in order to understand the whole BOOT Procedures.

Anyway, I am grateful to you for all your attention

Wail

Santosh Athuru said:

Hi Wail

I understand your question, Let me try to clarify this . 

As mentioned in Table 2.4 one of the boot mode GPIO configuration allows Piccolo to boot from SCI (TRSTn == 0 && GPIO37 == 0 && GPIO34 == 1) and one other boot mode configuration is 'GetMode()' (GPIO37 == 1 && GPIO34 ==1 & TRSTn == 0). As you have understood and mentioned this GetMode() configuration/setting allows bootROM to decode the boot mode by reading OTP_KEY and OTP_BMODE values.

Above mentioned options are stand-alone boot options, when emulator is not connected to target (TRSTn == 0). But, when Emulator is connected to target (TRSTn == 1) then the boot mode options are decoded by values of EMU_KEU and EMU_BMODE.

Table 2.7 gives EMUBOOT configurations and Table 2.8 give Stand-alone boot configuration options in detail.

Now, as mentioned in Table 2.8, one of the possible configurations of OTP_KEY and OTP_BMODE settings is SCI_BOOT. In other words SCI_BOOT option can be choosen on Piccolo(s) in two ways - when booting the device in stand-alone mode.

1.> By configuring the boot mode GPIO(s)  as here: (TRSTn == 0 && GPIO37 == 0 && GPIO34 == 1) - SCI_BOOT

2.> By Configuring the boot mode GPIO(s) for GetMode() and programming OTP_KEY==0x005A and OTP_BMODE==0x01.

Now, as mentioned in Table 2.7, when booting the device with Emulator connected, SCI_BOOT can be choosen in two ways. By Configuring EMU_KEY and EMU_BMODE values to 0x55AA and 0x0001 respectively to select SCI_BOOT directly or by configuring EMU_KEY And EMU_BMODE to 0x55AA and 0x0003 to GetMode() from OTP_KEY and OTP_BMODE locations and programming OTP_KEY and OTP_BMODE to 0x005A and 0x01 respectively.

There is no difference in boot loading when SCI_BOOT is selected by either ways above.

YES, the below listed steps will work for you.

> Set by hardware TRST=0: GPIO37=0: GPIO34=1 - SCI
> Force a hardware RESET
> Send an stream of data with the same structure of the table 2.10
> After conclude the transference, the program will start imediately from Entry Point

Infact if you are booting through SCI, you should use the above listed sequence instead of trying to get to SCI_BOOT using GetMode() feature. GetMode() feature is recommended to be used when the preipheral you want to boot from, cannot be selected directly from boot mode GPIO(s), for ex: boot-from-I2C.

Feel free to let us know if you have any more questions or if you need any more clarifications.

Best Regards

Santosh

 

 

Great answer, Santosh - I've added some of this to the Wiki.

Cheers

Lori

Hallo Lori,

Many thanks also for you !!!

My conclusion regarding this issue is:

When we have a new component, it is not possible to load the First Program through GetMode() since all FLASH memory is empty, including OTP.
( except by emulation that combines actions of hardware ( TRST ) and software ( EMU_KEY and EMU_MODE ) )

Without Emulator, no way !!!

The solution is given by hardware, we have to load the First Program as disscused in this Forum.
( or by hardware using Parallel I/O mode )

After that, we can do by software (almost) everything we want !!!
( since we have loaded a program for it, of course )

Thanks for all

Wail

Hi Santosh,

I followed the steps listed bellow

> Set by hardware TRST=0: GPIO37=0: GPIO34=1 - SCI
> Force a hardware RESET
> Send an stream of data with the same structure of the table 2.10
> After conclude the transference, the program will start imediately from Entry Point

But the last step does not happen and after conclude the transference my code does not start.

However, I know the code was programmed because if turn-off power,  make GPIO37=1 (Getmode: Flash) and turn-on again it runs correctly.

Can you help me solve this ?

Thank you very much for your attention.

Denise