TMS320F28379D: OTP for Z1-BOOTCTRL and FLASH a code

Hi Furkan,

One thing you can check is to see if the application actually made it to the device. You can erase the flash of the device and then attempt the firmware upgrade again. Once this is done, are you able to perform a memory dump of the device contents, or see if the application reached the proper address in the CCS memory window?

Another thing to check is the map file for the application. 

Thanks and regards,

Charles

Hi Charles,

Thanks for fast response! I tried to erase flash of device (3-Erase CPU1) and firmware upgrade (1-DFU CPU1) but code was not runned. How can I check address for application? For example, did you mean if I run CPU1 with specific address (0x00080000), I could see some values on these address from UNIFLASH. Do I understand correctly?

>> Another thing to check is the map file for the application.

-- How can I do this step?

Thanks.

Best Regards,

Furkan S.

I would like to say one more thing. with this 0x0000015A value, bootpins will be GPIO84 and GPIO72 right? Also bootmode will be SCI. Default SCI GPIO pins are GPIO84 and GPIO85. GPIO84 pins are same for SCI and bootpins. Does this cause any conflicts?

Thanks.

Best Regards,

Furkan S.

Hi Furkan,

>How can I do this step?

To view the map file, after a project has been built in CCS, you can navigate to the Build Configuration folder and click on the file with the .map extension.

>Can I check address for application?

Within the map file, there should be an origin address for program codestart as well as the .text of the program.

>For example, did you mean if I run CPU1 with specific address (0x00080000), I could see some values on these address from UNIFLASH. Do I understand correctly?

If you load the application using CCS/Uniflash, then run CPU1, it should run the application as expected. If not, there may be an issue in how the project was built.

>I would like to say one more thing. with this 0x0000015A value, bootpins will be GPIO84 and GPIO72 right? Also bootmode will be SCI. Default SCI GPIO pins are GPIO84 and GPIO85. GPIO84 pins are same for SCI and bootpins. Does this cause any conflicts?

The 0x015A value that is placed at the BOOTCTRL register bit field for CPU1 refers to SCI Boot 0, which uses  GPIO84 and GPIO85. The BootPins themselves will still be GPIO84 and GPIO72 on the device (connected to the switch A:SW1). As alternative for SCI boot is to use a BOOTCTRL register bit field value of 0x815A which refers to SCI Boot 1, which uses GPIO28 and GPIO29. The serial flash host programmer uses GPIO28 and GPIO29 as default, as these are the same lines for UART communication using a USB-C cable. There would be a conflict using the host programmer with default, as it communicates through UART lines using GPIO28 and GPIO29.

Thanks and regards,

Charles

Hi Charles,

>> To view the map file, after a project has been built in CCS, you can navigate to the Build Configuration folder and click on the file with the .map extension.

- Okay, I found it in CPU1_FLASH folder. Thanks.

>> Within the map file, there should be an origin address for program codestart as well as the .text of the program.

- There is a line in .map file -> ENTRY POINT SYMBOL: "code_start"  address: 00080000

>> If you load the application using CCS/Uniflash, then run CPU1, it should run the application as expected. If not, there may be an issue in how the project was built.

- When I run blinky_dc (with debug from CCS) example for CPU1 FLASH, it works but after reset device (power reset) code wasn't runned.

>> The 0x015A value that is placed at the BOOTCTRL register bit field for CPU1 refers to SCI Boot 0, which uses  GPIO84 and GPIO85. The BootPins themselves will still be GPIO84 and GPIO72 on the device (connected to the switch A:SW1). As alternative for SCI boot is to use a BOOTCTRL register bit field value of 0x815A which refers to SCI Boot 1, which uses GPIO28 and GPIO29. The serial flash host programmer uses GPIO28 and GPIO29 as default, as these are the same lines for UART communication using a USB-C cable. There would be a conflict using the host programmer with default, as it communicates through UART lines using GPIO28 and GPIO29. 

- Do you recommend to use OTP with 0x0000815A command on new device? 

Thanks for everything Charles!

Best Regards,

Furkan S.

Hi Furkan,

>When I run blinky_dc (with debug from CCS) example for CPU1 FLASH, it works but after reset device (power reset) code wasn't runned.

Is the boot mode switch SW1 set to SCI boot mode (GPIO72 low, GPIO84 high) or is it set to Get Mode/Flash by default (GPIO72 high, GPIO84 high)? After a device reset, depending on the boot mode switch, the device will be operating from the boot mode determined by SW1 boot setting. It may not be running due to the SW1 switch not being set to Flash boot mode.

>Do you recommend to use OTP with 0x0000815A command on new device?

If you plan to boot from SCI using GPIO28/GPIO29 w/o CCS, then yes. However, you should take caution to know that this would be a permanent change to the device and that by writing the OTP with this value, the other default boot modes (Parallel I/O, Wait, Get Mode/Flash default) associated with the Boot Mode switch will stay as previous.

Thanks and regards,

Charles

Hello Charles, I hope you are well.

>> Is the boot mode switch SW1 set to SCI boot mode (GPIO72 low, GPIO84 high) or is it set to Get Mode/Flash by default (GPIO72 high, GPIO84 high)? After a device reset, depending on the boot mode switch, the device will be operating from the boot mode determined by SW1 boot setting. It may not be running due to the SW1 switch not being set to Flash boot mode.

-- Yes, It was Get Mode for using OTP mode. GPIO72 and GPIO84 were high. Additional, A:SW1 was 0 0.

>> If you plan to boot from SCI using GPIO28/GPIO29 w/o CCS, then yes. However, you should take caution to know that this would be a permanent change to the device and that by writing the OTP with this value, the other default boot modes (Parallel I/O, Wait, Get Mode/Flash default) associated with the Boot Mode switch will stay as previous.

-- I just want to use OTP for  SCI boot option. Here, these are my steps which I did it for SCI Boot.

Step-1: Using UNIFLASH to write 0x0000015A value to Z1-BOOTCTRL address.

Step-2: Reading device memory to check 0x0000015A value from 0x7801E address and it seems okay.

Step-3: Connecting device GPIO84 & GPIO72 via TTL USB to computer.

Step-4: Testing blinky_dc_cpu01 with F2837xD_sci_flash_kernels_cpu01 kernel file from <C2000Ware_5_02_00_00>\utilities\flash_programmers\serial_flash_programmer\f2837xD_fw_upgrade_example folder.

Step-5: 1-DFU CPU1, 0-DONE from serial_flash_programmer.exe. (It is not working).

Step-6: I tried Step-5 with this commands and led was blinking but after reset power, code was not runned. (1-DFU CPU1, 11- RUN CPU1 and hex. address 0x00080000). You can see on Figure-2

Fig2. Operation Pannel with RUN CPU-1 Command.

Is there any error on these steps Charles? Could you tell me all steps to use OTP for SCI. Because I will do these steps on new device and I don't want to do wrong thing.

Thanks for everything Charles.

Best Regards,

Furkan S.

Hi!

Can anyone help me for this issue?

Best Regards,

Furkan S.

Hi Furkan,

I'll be able to update you further by end of day.

Regards,

Charles

Furkan, 

If you have taken the steps from 1-6 and used the host programmer to successfully download the kernel and application, these are correct. Clarify on me if this is indeed how Fig.2 was generated.

The entry point address you placed at the host programmer is 0x80000. The address shown in the snapshot for the application is 0x82aa5. I believe this may be the reason why it is having issues.

Thanks,

Charles

Hello Charles,

>> If you have taken the steps from 1-6 and used the host programmer to successfully download the kernel and application, these are correct. Clarify on me if this is indeed how Fig.2 was generated.

-- Fig.2 was ended with success and led was blinking after this step. When I reset the power of device, led wasn't blinking. I think code can't start automatically. If I use serial_flash_programmer_appln.exe with this command: .\serial_flash_programmer_appln.exe -d f2837xD -k f2837xD_fw_upgrade_example\F2837xD_sci_flash_kernels_cpu01_alt.txt -a f2837xD_fw_upgrade_example\blinky_dc_cpu01.txt -b 76800 -p COM10 and giving 1-DFU CPU1, code was running again. You can see it on Fig.3

Fig3. Serial Flash Programmer Appln

>> The entry point address you placed at the host programmer is 0x80000. The address shown in the snapshot for the application is 0x82aa5. I believe this may be the reason why it is having issues.

-- I think there is no problem on this step. Because I tested with 0x82aa5 address and it stopped blinking after power reset. I mean code couldn't jump (branch) to application. I really need help for this issue. 

Best Regards,

Furkan S.

Hello Charles, I have an update. After I send "AA" or "aa" message from serial (for example with PuTTY) to card after reset process, code was running and led was blinking but every reset, should I send this message from serial? 

Best Regards,

Furkan S.

Charles,

Thanks for your response. So I am understanding, I should send 'AA' message from UART on every power reset to change boot mode from SCI (OTP value) to Flash Boot. Your TRM is not enough for this sequence... 

Best Regards,

Furkan S.

Charles, 

I have one more question. If I change Zx-BOOTCTRL.OTP_KEY with 0xFF instead of 0x5A, it will be Boot from Flash? Am I wrong? For example, I am thinking change Z1-BOOTCTRL --> 0x000081FF, now it will use SCI Alternate, boot pins will be GPIO84&GPIO72 and OTP_KEY won't be equal 0x5A. Is it valid for SCI Alternate IO and jumping to FLASH step? You can see this steps on Fig 4.

Fig 4. Standalone and Hibernate Boot Flow

Hi Furkan,

Changing the MSB of the keyvalue to any variation of 0xFF will state that the BOOTCTRL register is not valid. It will default to the boot mode switch value. 

If you are following the flow chart diagram for the SCI Alternate IO, it will be valid if the keyvalue is set (ex. 0x0000815A)

Thanks and regards,

Charles

Hello Charles,

>> Changing the MSB of the keyvalue to any variation of 0xFF will state that the BOOTCTRL register is not valid. It will default to the boot mode switch value. 

-- Yes, I understand. I mean, after changing SW1: 0 | 1 (SCI BOOT), it will look to OTP_BMODE. OTP_BMODE will be 0x81 (SCI Alternate). After SCI Boot, I will change SW1: 1 | 1 (GET MODE) and it will look OTP_KEY. So it won't be equal 0x5A and it will be BOOT from FLASH. Am I right?

Best Regards,

Furkan S.

Hi Furkan,

With SW1: 0|1 (SCI Boot), the device will look to default GPIO pins for firmware upgrade (GPIO84 & GPIO85) using BMODE 0x01 (SCI default). 

With SW1: 1|1 (GET MODE) and OTP_KEY not being set to 0x5A, it will Boot from FLASH.

If SW1: 1|1 (GET MODE) and OTP_KEY is set, along with BMODE to 0x81, it will Boot from SCI Alternate. Note that if this is set through OTP, you will not be able to use FLASH BMODE anymore on the device.

Thanks and regards,

Charles

Hello Charles,

>> If SW1: 1|1 (GET MODE) and OTP_KEY is set, along with BMODE to 0x81, it will Boot from SCI Alternate. Note that if this is set through OTP, you will not be able to use FLASH BMODE anymore on the device.

-- I mean If I set SW: 0 | 1 (SCI MODE) and OTP_KEY is setted to 0xFF (not 0x5A) with BMODE to 0x81, will it boot from SCI Alternate Mode? After this step (Boot from SCI Alternate) If I set SW: 1 | 1 (GET MODE), it will Boot from FLASH. Am I right?

Best Regards,

Furkan S.

Hello Charles,

Thanks for your response. I have one more question about these steps. I would like to write write OTP_KEY --> 0x5A, BMODE --> 0x81. With this values, my card always will wait on SCI Alternate Boot . After boot process, I want to jump to flash without writing 'A' or 'a' character. What should I do?

Best Regards,

Furkan S.