CCS/TMS320F28069: TMS320F28069 Bootloader from SCI to SPI procedure

Eli Arad33

Part Number: TMS320F28069
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

I am in a process of developing , or we can call it continues integration of the F2806X boot loader. ( actually it is 28065)

I will described the steps I understood to get the SCI bootloader and then my understanding about the SPI bootloader.

If one can comment and add his thoughts. i did not started yet.

I am planning do use CCS to load the flash_f28069 example from controlSuite: C:\TI\controlSUITE\device_support\f2806x\v151\F2806x_examples_ccsv5

This is the only example that work from flash. all ~20 examples are working from RAM.

if i understand correct, working from RAM means that when i load the firmware using JTAG , next time i will do power cycle it will need to be download again, where

working from flash, it means that the application\firmware will burned in flash and even if i do power cycle i can just power on and the application\firmware will run.

If so , going to SCI boot loader,

I need to:

1. compile the f28069_flash_kernel example (C:\TI\controlSUITE\device_support\f2806x\v151\F2806x_examples_ccsv5\f28069_flash_kernel)

This example is already in SCI ( the SCI_boot.c) is in the project.

perform hex2000 on the output to get the hex file

2. perform hex2000 on the example flash_f28069

When i have those two hex file , I will need to do the make GPIO 34( make it 0) and GPIO 37 ( make it 1) in GPIOB

as it shown in the bootrom sources:

BootMode = GpioDataRegs.GPBDAT.bit.GPIO37 << 1;
BootMode |= GpioDataRegs.GPBDAT.bit.GPIO34;

Power cycle the board and then the bootloader will wait for the two files , which will be supplied using the flash_programmer command line tool:

serial_flash_programmer.exe -d f28065 -k flash_kernels_f28065.txt -a flash_28065.txt -p COM7 -b 9600

where the .txt file are the output from the hex2000 file.

Hitting 'a' will start the loading.

The original flash_28065 was already loaded using JTAG and now it will be replaced by the serial_flash_programmer?

And to conclude, this is the bootloading procedure.

please confirm the above steps.

Now going to SPI bootloader.

This is not well documented , so please confirm my steps here.

I will replace the SCI_boot.c file from the flash_kernel_f28065 project with the SPI_Boot.c that i found in a project called bootrom for f2806x.

if i understand correct , the bootroom project does not need to be loaded and does not have a rule in this bootloading game , we just can use its sources to select which boot mode we want.

So after i replace the SCI_boot.c with SPI_boot.c , I will compile and create again with the help of hex2000 a txt file.

Now, i cannot use any more serial_flash_programmer, because it is working with SCI( Uart)

My goal is to do the firmware upgrade via SPI under Linux.

So next step is to understand the code of the serial flash programmer ( sources were given in visual studio) and to create a Linux C program ( using spi_dev interface) to do the same. ( if there is such a tool in SPI linux please let us know)

Once I will do so , I should have the bootloader work from SPI.

But , not before I will have to program the OTP at address:

#define Get_mode (Uint16 (*)(void))0x3D7CC0

to have value of 4 there ( SPI )

to do so, i read this thread https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/167270

which explain how to do that using the code it self. If there is a different method ( maybe using CCS and JTAG please let me know)

GPIO 34 and GPIO 37 need to be both 1.

and TRST need to be 0 in both SCI and SPI ( TRST is a gpio also ?)

What if i mistake in program the OTP to values of 4? do i need to throw away the chip because it is one time programming?

What if i want to do SCI bootloader and the SPI just to check?

If i understand correct , the logic of determine the bootmode ( GPIO and OTP) is already in the bootrom, and cannot be changed ??

First , thanks if you read it until here.

This long story of getting the bootloader to work in TI is not so easy as it should be.

If you see anything wrong , have something to comment please do, help me and many others out there.

Thanks!

over 7 years ago

0 Sal Pezzino over 7 years ago

TI__Mastermind 32995 points

Hi,

Your understanding of flash and RAM programmation is correct.

Your understanding is largely correct.

You do not need to manually send 'A'. The serial flash programmer will do this to perform the autobaud lock.

The ROM bootloader loads the kernel into RAM. Then the kernel executes and loads the flash application and programs it into flash replacing the existing code in those sectors which have been erased and programmed by the flash kernel.

You may be able to replace SCI_boot.c with SPI_boot.c and use the same Shared_boot and CopyData() files and functions. You will need to confirm this and test it.

Correct. The serial flash programmer will not work for SPI. But you may be able to use a USB to SPI converter and use most of the code in the serial flahs programmer to port it to a SPI solution.

The boot modes cannot be changed.

Please also see www.ti.com/lit/sprabv4

Let me know if I missed any of your questions. And I will be glad to help.

Regards,
sal

0 Eli Arad33 over 7 years ago in reply to Sal Pezzino

Prodigy 110 points

Hi

Can you please focus on the OTP part:
As understood , we need to program the OTP to have the value of 4 in the boot_mode address
#define Get_mode (Uint16 (*)(void))0x3D7CC0
each chip have slight different address, the 28069 have the above value.

The only place i found how to program the OTP was the link in this community:
several questions and issues:
1. Does TI have a graphic way of programming the OTP , maybe using CCS it self?
2. What is the sense of having the OTP select the boot mode, why not having 3 gpios. in that way we can go back and forth between interfaces without replace the chip.
3. If the answer for 1 is that there is not tool , does the explanation of the linker command is correct? can i use any example , add the linker command and burn the OTP? do you have a linker command ready for programming OTP?
4. Do you have another way you can suggest to program the OTP for SPI ( value of 4)

This is important , because one mistake here , destroy the chip.
and buying a new board or replacing the chip is a very big issue.

Thanks!
Eli

0 Sal Pezzino over 7 years ago in reply to Eli Arad33

TI__Mastermind 32995 points

Hi,

1) Yes. In CCS there is an On Chip Flash Programmer. After connecting, click on Scripts and you should see On Chip Flash Programmer. You can specify which value you want to program.
2) Boot mode selection has evolved over the years. But on this device, it was determined that having 3 GPIOs for boot mode selection would have constrained the user in regard to their GPIO availability.
3) You can also use the linker command file and a CCS project / .out to program the OTP. Just make sure you are programming the correct value in the correct location before loading and programming the .out image onto the device via JTAG or serial flash programmer.
4) On Chip Flash Programmer is your bests bet in my opinion.

Regards,
sal

0 Eli Arad33 over 7 years ago

Prodigy 110 points

Hi
You said:
"You may be able to replace SCI_boot.c with SPI_boot.c and use the same Shared_boot and CopyData() files and functions. You will need to confirm this and test it."

Why may be able? why to confirm?
Is it not the right way to get a flash kernel that work via SPI?
Is there a different or TI right way to do so?

Is there any where in the world a document, project , or any kind of information that shows how to get the boot loader machnisem to work via SPI?
Thanks
Eli

0 Sal Pezzino over 7 years ago in reply to Eli Arad33

TI__Mastermind 32995 points

Eli,

The main thing that would have to change from the SCI flash kernel is the GetWordData function. You should be able to point that function pointer to a SPI function which is in SPI_boot.c

Please go ahead with my recommendation and reply with any specific questions you have. The SCI flash kernel and serial flash programmer is a utility meant to provide customers with an SCI solution and the tools necessary to extend it to SPI or other serial communication peripherals.

Hope this helps.

sal

0 Eli Arad over 7 years ago in reply to Sal Pezzino

Prodigy 40 points

Hi Sal,

First I managed to get the SCI working as described above. ( i put trst to 0 . gpio 34 to 1 and 37 to 0 , use the flash kernel and my app both after hex2000 and it works!)

But about SPI boot loader.

I want to be sure about how to enter to spi boot and how just let the chip boot normally from flash

from this document:

http://www.ti.com/lit/ug/sprugo0b/sprugo0b.pdfx

We can see that there are two tables

Standalone and emulation.

Where stand alone supports SCI , parallel and WAIT ( where wait is the debugger , right?)

and Emulation mode table.

emulation mode is the one i need (i think)

and why.

After iI will program the otp bootmode to 4

I will need to work with trst =1 ( the only gpio no that i will need for the project)

Where gpio 34 and 37 are out of the game any more.

So now , i will need to put trst to 1 and change the emukey and emuboot more which are flash ( not otp) memory location!

And using that emulation boot mode i will need to once boot to spi to upgrade the firmware and to also boot normally from flash.

Please confirm.

Second question.

It apears that i missed the fact the SPI_Boot is a master and it wants to work with SPI Slave device to read the flash kernel and my app ( converted to .txt using hex2000 utility)

So i need to write a Linux SPI Slave device which will transfer the .txt files to the SPI_Boot?

(If so , this is not very convenient when working in Linux where the SPI driver is mostly master and to use it as a slave is not straight forward)

Thanks

Eli

0 Sal Pezzino over 7 years ago in reply to Eli Arad

TI__Mastermind 32995 points

Hi Eli,

Section 2 of the Technical Reference Manual and Figure 2-9 will be helpful for you. www.ti.com/lit/spruh18

You can use emulation boot mode to set the boot mode. But I am not sure why this would be helpful for you since, you need to have the emulator connected, and if your emulator is connected, why not just use (i.e. JTAG and CCS) to program the flash.

For when you are running from standalone, you will need to program the GET_MODE value to SPI bootloader. But then you will loss your ability to boot to flash. Alternatively, you can always boot to flash and set up your application that when it receives some external command, it will branch to the SPI bootloader or a SPI kernel which already resides in flash, which will then begin to update the flash with a new image.

The SPI on the MCU is a master. This may not be ideal for your application which is trying to use a Linux machine to update the device, but it is a good scenario when communicating with other MCUs.

Hope this helps.
sal

0 Eli Arad33 over 7 years ago in reply to Sal Pezzino

Prodigy 110 points

Hi Sal

This person here:
e2e.ti.com/.../1946958
say that it will always boot from SPI like you are saying, but when there is no slave device connected , he answers it will boot to flash.
If so we can live with that.

Again the idea of the project is as following.

We need to update the MCU firmware via SPI when it connected to embedded linux (IMX6)
to overcome the problem of Linux not having SPI Slave i am thinking or writing a Linux character device that do the SPI Slave with GPIO bit banging, and implement the protocol that the bootloader MCU require.

If the chip will always boot to SPI and not to flash of course it will not help.
but if the Christopher Chiarella is right , then it i can simulate that the SPI slave is not exist ( i will not load the spi slave driver)

Now i understands that TI did not consider that option of bootloading from SPI from Linux but only from EEPROM devices .
This why this thread is long and i need your confirmation because it can take lots of time to get it working.

Thanks,
Eli

0 Sal Pezzino over 7 years ago in reply to Eli Arad33

TI__Mastermind 32995 points

Christopher Chiarella is correct. If there is no proper slave connected, then as the SPI bootloader begins, it will fail and automatically boot to flash.

I suggest you test this as well. So you can have a better understanding of this and observe it.

Regards,
sal

C2000™︎ microcontrollers

C2000 microcontrollers forum

CCS/TMS320F28069: TMS320F28069 Bootloader from SCI to SPI procedure