Bootloader Using SCI Only with no GPIO - TMDX28069USB

Sorry, my post didn't include the screen shot for some reason. See the image above.

Thank you for reading the App Note.

Is your device locked?
If so, then you will not be able to use the SCI boot loader to load the kernel into secure RAM. You will need to move the kernel into unsecure RAM.

In order to unlock the device, you will need to load the CSM keys into the CSM key registers.

To help debug, you can also load the Boot ROM symbols when connected via JTAG to confirm you are booting the device to the correct SCI bootloader.

Regards,
sal

I apologize for not replying sooner.

It turns out that there really was no way around making hardware changes such that GPIO37 is held low and GPIO34 is held high. Some board modifications were made to do this. On the controlSTICK, R9 was moved such that it's no longer connected to the 3.3V but still tied to pin 56 (GPIO37/TDO) of the MCU. The other end of R9 is now tied to Pin 16 (I'm referring to pin 16 of the J1 pins on the end of the controlSTICK). After that, I wired pin 4 of J1 directly to pin 30 of J1 and I also tied pin 16 of J1 to pin 32 of J1.

After doing all of this, and executing the same commands as before, the bootloader worked properly.

However, now I face a separate issue: when I attempt to use set or clear any of the GPIO, the serial loader won't work properly. It'll still load the flash kernel, but doesn't appear to complete loading the application code. The were no errors generated when I built the project. However, if I remove the lines of code that sets/clears GPIO, then the serial loader will load the application code.

This doesn't really make any sense, but I'll continue to investigate this.  

Which GPIOs for SCI communication is your board using?

Which GPIOs is the sci flash kernel compiled to be using?

This may be the issue.

sal

Based on the SCIA_Init() function in f28069_flash_kernel, pins 28 and 29 are being used for SCIA communication. According to the "Piccolo F28069 controlSTICK" schematic, this corresponds to pins 40 and 34 respectively. Also based on that schematic, it doesn't appear to be tied to anything.

Therefore, since nothing is tied to pins 40 and 34, it would make sense that serial loader wouldn't complete. However, what is confusing is this: after I tied GPIO34 to 3.3V and GPIO37 to ground, the serial loader reported that it loaded the flash kernel successfully.

How could it have done this if pins 40 and 34 aren't tied to the USB? I thought that the hex information for both the flash kernel and the application was being transferred over SCI. If the pins being used for SCI aren't tied to the USB, then why would the serial loader say that the kernel was successfully loaded?

Are you able to continue to make progress after loading the kernel in this way? Meaning are you able to load the flash application?

There are probably two SCI boot modes on your device. Can you check to see if the alternate SCI bootloader has the pins it is using connected to the USB?

sal

No, I'm still not able to load the application code into flash.

As far as the "alternate SCI bootloader" I don't think there is one on my device. Since the flash kernel is being loaded in to RAM, and RAM is volatile, I would figure that everytime I plug/unplug the device, the RAM would be cleared. As a result, when I run the serial loader, it would only load the one flash kernel into RAM.

It seems that the FTDI chip on the controlSTICK is used to connect GPIO pins to the USB COM port (see section 6.1.2 of "Serial Flash Programming of C2000 Microcontrollers"). I took a look at datasheets for both the x28069 controlSTICK and the FT2232D (the FTDI chip used on the controlSTICK). It looks like there are two channels - A and B. Channel A is being used by  TCK, TDI, and TDO of the x28069. These aren't the TX/RX pins GPIO 29 and 28. Therefore, it would seem to me that I would need to connect pins 34 and 40 of the x28069 to pins 40 and 39 of the FT2232D in order to utilize channel B and satisfy the hardware requirement for SCI. Does that sound right to you or am I incorrect?

By the way, thank you for the help so far Sal, it's much appreciated.

After taking another look at the controlSTICK schematic, it does appear that GPIO 28 and 29 are physically tied to the FTDI chip that's on the stick. It's tied to pins 39 and 40 of the FTDI chip.

I'll put the flash kernel in debug and open Realterm and enter the hex values one by one to step through the program. This will determine if there's an issue in the flash kernel. I'll also step through the serial loader in visual studio to see if there's a problem there.

When I find out the issue, I'll post it here.

I wanted to give an update on my progress. It turns out that serial loader will successfully load the following application program: "controlSUITE\device_support\f2806x\v151\F2806x_examples_ccsv5\flash_programming".

Furthermore, if I load my test application after cycling power (again through serial loader) it works also.

Therefore, I need to determine what properties of flash are being changed such that my test application works. I would assume that whatever changes that make it work are being done to flash since in the procedure I described, power was being cycled. Therefore, the only settings that should remain should be in flash.

I finally got my test application to completely load using the serial loader. It required a few adjustments:

1. I had to unlock CSM in my application.

2. In "f28069_flash_kernel" -> "Shared_Boot.c", CopyData() originally erased flash sectors A thru D. However, it didn't erase sectors E, F, G, or H. Therefore, small applications could successfully load into flash without any modifications. However, my test application used addresses in the other sectors. Thus, because those sectors were never erased prior to loading into flash, the test application couldn't correctly load. After I included sectors E, F, G, and H in the erase function arguments, my test application was able to load successfully.

Thanks Sal for the help, it's much appreciated.

Wonderful! Glad you got it working.

Please verify one of my above responses to close the thread. Thanks!

sal