TMS320F28379D: SW1 on controlCARD mounted upside down

Thomas, I can help you with Q1. If you have a picture of your board I would appreciate it.

If the switch is upside down then Position 1 and 2 will be reversed. additionally if the guide recommends "up" this would mean down...

• Lets say the guide says "position 1 down" you should put position 2 up.
• If the guide recommends ON or OFF, those should not be reversed, for example if it says "position 1 ON" then put position 2 ON.

A colleague of mine should help with the other questions. Anu Biradar

Regards,
Cody 

Thomas, 

For Q2 - Please refer to the F2837x section of the FAQ of the flash kernel app note: https://www.ti.com/lit/an/sprabv4e/sprabv4e.pdf 

This gives you step by step instructions on how to run the flash kernel example on the F2837xD control card with the serial_flash_programmer utility. 

For Q3 - This example demonstrates Flash API usage, it is not intended to be passed into the -k parameter of the serial_flash_programmer. 

Thanks,

Anu

Cody or Anu -

From what I can tell, the sci_flash_kernels example program provides no way to specify which flash sector should be programmed. The example program flash_programming does, but it is hard-coded to program flash sectors B and C. It programs nothing useful into flash. Both projects seem to simply demonstrate use of your flash API.

Does TI have an off-the-shelf utility that uses serial_flash_programmer with a flash kernel B to program a specified flash sector on a F2837xD DSP without the user having to build his own from your examples of the flash kernel API?

Having found none, I have made a new CCS project based on example program flash_programming. I named it program_flash_sector. My program is hardwired to program a specific flash sector. I refactored the example code by defining  functions named EraseFlashSector and ProgramFlashSector. Sector selection is based on an enum list. The enum is used to look up sector addresses.

When I run this to program the controlCARD example project blinky to CPU1, the message "NACK Error with sending the Function Packet" is displayed. It is clear that I am doing something wrong. Can you tell me what in my implementation is creating the problem? Or perhaps my entire approach is flawed.

I would like to upload the source rather than embed lengthy source code in my reply. I attempted to do that using your forum Insert file tool, but it would not allow me to upload a ZIP file. My ZIP file includes both the CCS project and a Windows batch file to encapsulate parameters sent to the serial_flash_programmer utility. Please let me know the best way to get these files to you.

Thomas, 

Thomas Cox said:

From what I can tell, the sci_flash_kernels example program provides no way to specify which flash sector should be programmed.

This is correct, the flash kernel does not have a way of specifying what sectors to program. This is determined by the linker command file of your application. Your application will be written to whatever sectors you assign the application to in its linker command file. 

Thomas Cox said:

The example program flash_programming does, but it is hard-coded to program flash sectors B and C. It programs nothing useful into flash. Both projects seem to simply demonstrate use of your flash API.

This is intentional, as you said this example is to demonstrate Flash API usage, while the flash kernel example is used to perform a firmware update. 

Thomas Cox said:

When I run this to program the controlCARD example project blinky to CPU1, the message "NACK Error with sending the Function Packet" is displayed. It is clear that I am doing something wrong. Can you tell me what in my implementation is creating the problem? Or perhaps my entire approach is flawed.

What command are you passing into the serial_flash_programmer, and what are you passing in the k and a parameters? Have you tried running the example as specified in the app note I linked in my previous reply?

Once we have discussed these topics, we can try to take a look at the source code. 

Anu

Anu and Cody -

Thanks for your replies. I now have a better understanding of the intended use of the flash_programming example code and the serial_flash_programmer.

My ultimate goal is to be able to copy 3 identical hex files to 3 different flash sectors. At power up the boot loader will verify compare checksums of the 3 copies and proceed only if all 3 match. The boot loader will then copy the hex file from the primary flash sector into RAM and start execution in RAM.

With the limitation that sector can only be specified in the hex file, and not in the flash programming application, I don't see how I can achieve my goal using serial_flash_programmer. It would be able to program the boot loader, but not install the 3 hex file copies to be copied to and executed from RAM.

Returning to my simple exercise to demonstrate that I can get serial_flash_programmer to copy a hex file that was designed to run from flash into the sector specified by its link cmd file: I am trying to program the FLASH build configuration of the blinky example program for the controlCARD to flash sector C, as specified in the link cmd file. The command is executed from the blinky project CPU1_FLASH folder which holds the build products. The parameters being passed to serial_flash_programmer are:

    -d f2837xD
    -k ..\targetConfigs\F2837xD_sci_flash_kernels_cpu01.txt
    -a .\blinky_cpu01.hex
    -p COM4
    -v

When I select option 1 DFU CPU1 from the option menu, the response is NACK Error with sending the Function Packet... Please press Ctrl-C to abort.

Downloading .blinky_cpu01.hex to device... Checksum does not match... Please press Ctrl-C to abort.

Do you need any additional information?

Thomas,

Thomas Cox said:

With the limitation that sector can only be specified in the hex file, and not in the flash programming application, I don't see how I can achieve my goal using serial_flash_programmer. It would be able to program the boot loader, but not install the 3 hex file copies to be copied to and executed from RAM.

For your specific implementation, you may want to create a custom host program. 

Thomas Cox said:

Returning to my simple exercise to demonstrate that I can get serial_flash_programmer to copy a hex file that was designed to run from flash into the sector specified by its link cmd file: I am trying to program the FLASH build configuration of the blinky example program for the controlCARD to flash sector C, as specified in the link cmd file. The command is executed from the blinky project CPU1_FLASH folder which holds the build products. The parameters being passed to serial_flash_programmer are:

    -d f2837xD
    -k ..\targetConfigs\F2837xD_sci_flash_kernels_cpu01.txt
    -a .\blinky_cpu01.hex
    -p COM4
    -v

I would recommend using the files in the C2000Ware_4_01_00_00\utilities\flash_programmers\serial_flash_programmer folder. The f2837xD_fw_upgrade_example has a F2837xD_sci_flash_kernels_cpu01_alt.txt file that is built with GPIO pins 28 and 29 to be used for SCI communication, which is what we want when using the control card. You can also use the blinky_dc_cpu01.txt as the application file, this will be aligned to 128 bit boundaries, which is also what is needed when performing firmware upgrades using flash kernels. Run the serial_flash_programmer.exe from this directory. Be sure to set up the control card as specified in the app note prior to using the serial_flash_programmer. 

Thanks

Anu

Anu -

I am using GPIO 84 & 85 (option 1) instead of GPIO 28 & 29 (option 2) for SCI-A for several reasons. I do not want to program flash over the USB port, and GPIO 28 & 29 are linked to the USB port. I am using the controlCARD to prototype flash programming for my client's proprietary PC board, which is designed to use GPIO 84 & 85, and does not provide the option of using GPIO 28 &29. And I am in parallel investigating use of the Elprotronic FlashPro2000 flash programmer, which according to the vendor works only on GPIO 84 & 85, probably for the same reason, that GPIO 28 &29 are tied to the USB port. Is there any reason I should NOT use GPIO 84 & 85 on the TI controlCARD?

Thanks for the info on 128 bit alignment. I checked out the blinky_dc project, and found that DC stands for dual core. We have no reason to use CPU2 at this time, and I don't want to add that level of complexity at this time.

I did import the project binky_dc_cpu01. I found that it uses the same link file 2837xD_Flash_Sector_CPU1.cmd as blinky_cpu01, which has directives ALIGN(8), which I understand to mean a 64-bit memory alignment.

I modified the blinky application by using my own revised link cmd file that sets 128 bit memory alignment by using ALIGN(16) directives in place of the ALIGN(8) directives in the C2000ware version. It still produces the same NACK and Checksum error messages that I cited earlier. Do I need to take a different approach to assigning 128-bit memory alignment?

Thomas, 

Thomas Cox said:

Is there any reason I should NOT use GPIO 84 & 85 on the TI controlCARD?

Please see the screenshot below from the app note:

The errata section referenced in the previous screenshot: 

Thomas Cox said:

Do I need to take a different approach to assigning 128-bit memory alignment?

ALIGN(8) is 128 bit alignment, not 64 bit alignment, for the C28x cores. You should modify your linker command file in accordance. 

Thanks

Anu

Re: GPIO pin assignments for SCI-A on the controlCARD. I read all the documents related to TI controlCARD and Serial Flash Programming for a controlCARD. I have board version 1.3B and the only manual I had been able to find prior to you providing the link for Rev B was the manual for board v1.3A. I found no substantial differences on the topic between the two revs.

I did notice that the App Note Serial Flash Programming of C2000 Microcontrollers was published in 2019 and the Rev B user guide for the TI controlCARD rev1.3B was revised in June 2022. If the Rev B controlCARD has the limitation that ONLY GPIO 28 & 29 can be used in SCI boot mode, why is that not stated? Language in p4 Notes for all controlCARDS implies that either GPIO 28 & 29 or GPIO 84 & 85 can be used. Description of A:SW1 position 2 does not clearly state the impact of disconnecting the USB interface.

After reading all this, it sounds like you are saying the only GPIO connection supplied on the control CARD to SCI-A is through the FTDI US-to-serial chip - that GPIO 84 & 85 cannot be connected to SCI-A and that if A-SW1 position 2 is set to bypass the FTDI USB-to-serial chip, then any connection between SCI-A and GPIO28 & 29 is removed. In other words. the only choice to connect to SCI-A is over the USB connector, which cannot be bypassed without disabling any and all GPIO connection to SCI-A.

This would be a serious limitation. It also conflicts with the fact that, working with Elprotronic to program blinky using their FlashPro2000 adapter DOES work when connected through the DOCK board to GPIO-84 & 85. And given that success, it seems it should be possible that I can use GPIO 84 & 85 to connect to SCI-A on the Rev. 1.3B controlCARD when using the serial_flash_programmer application.

Re: the 2nd topic, 128 bit alignment: My copy of the blinky project for CPU1 already had ALIGN(8) specifiers in the supplied link cmd file 2837xD_FLASH_lnk_cpu1.cmd. You had said I had to use blinky_dc to get 128 bit alignment, so I thought the ALIGN(8) directives were for 64-bit alignment.Again, I was able to program blinky built using ALIGN(8) directives and the FlashPro2000. I was unable to find a good description of the ALIGN directive in any document, including the document Advanced Linker Techniques for Convenient and Efficient Memory Usage by George Mock. I have restored the ALIGN(8) directives in the cmd file for blinky.

Thomas, 

For your ControlCard specific questions, Cody Watkins is the better person to answer.

Regarding the 128 bit alignment, glad the ALIGN(8) was already present, this sometimes is not the case for the linker command files. You can use the blinky example you have if it is already 128 bit aligned. 

Anu

Going back to my post from 3 days ago...

Re: my simple exercise to demonstrate that I can get serial_flash_programmer to copy a hex file that was designed to run from flash into the sector specified by its link cmd file: I am trying to program the FLASH build configuration of the blinky example program for the controlCARD to flash sector C, as specified in the link cmd file. The command is executed from the blinky project CPU1_FLASH folder which holds the build products. The parameters being passed to serial_flash_programmer are:

    -d f2837xD
    -k ..\targetConfigs\F2837xD_sci_flash_kernels_cpu01.txt
    -a .\blinky_cpu01.hex
    -p COM4
    -v

When I select option 1 DFU CPU1 from the option menu, the response is NACK Error with sending the Function Packet... Please press Ctrl-C to abort. Downloading .blinky_cpu01.hex to device... Checksum does not match... Please press Ctrl-C to abort.

The build of blinky_cpu01 has no changes from the example I imported. The data exchange over SCI IS occurring. What would cause the DFU CPU1 operation to show a NACK error? If there is a NACK error, why does execution seem to continue? What checksum does not match and how can that be corrected?

Thomas, The controlCARD is not specifically limiting the GPIOs. Any GPIOs supported in the bootloader are possible as long as the pins are accessible in the cCARD.

The note you mentioned is there because we have a lot of customers who connect the JTAG USB connector and think that now magically any SCI peripheral and pin combination will now work over USB. The note is to call out that the SCI boot loader can be used with GPIOs 28 and 29 though the XDS to a terminal application. if you configure the device SCI boot for another set of GPIO there is nothing stopping you from connecting to those pins directly, it simply wont communicate though the USB connector... which as far as i can tell is obvious to you. Thanks for being thorough.  

Regards,

Cody 

Cody - Thanks for your reply re: SCI capabilities accessible through GPIO pins on the TI controlCARD.  However, neither you nor Anu have replied directly to the latest blocking issue I am encountering when I try to use the serial_flash_programming utility with the F2837xD_sci_flash_kernels implementation of flash kernel type B to program the blinky example program to flash.

Can either of you tell me what might be causing a NACK error when I attempt to execute the DFU CPU1 menu option, and what I might do to be able to proceed from that point?

Thomas,

Sorry for the delay, I was out of the office all last week. I am only here to support the HW issues, of which I believe are resolved.(feel free to let me know if you need more support) The software issues fall on Anu Biradar's side of the fence. If you feel you are not getting sufficient answers then perhaps I can send the thread back to the moderators and ask them to reassign, although I cant guarantee that will help.

Regards,
Cody  

Cody - thanks for your reply. I realize that my question falls within Anu's realm of expertise. I have looked at source for serial_flash_programming and sci_flash_kernels, and don't see what might be causing the NACK error immediately after attempting to execute the DFU_CPU1 menu option.

Thomas, 

You need to be using GPIO pins 28 and 29 when using the control card and running the serial flash programmer on a PC. The NACK error is probably because the SCI peripheral on the F2837xD isn't configured correctly for this example.

Anu

As I said in an earlier reply, I believe I can use GPIO 84 & 85 to drive SCI-A during flash programming for several reasons. 1) The Elprotronic FlashPro2000 is able to program the blinky example program into flash using GPIO 84 & 85. It fails when using GPIO 28 & 29. 2) The serial traffic at the start of the program that is echoed on the command window console before the menu is displayed identically for both GPIO pairs. 3) When I attempt to use serial flash programmer with GPIO 28 &29 and calling SCI_GetFunction(SCI_B0OT_ALTERNATE) instead of SCI_BOOT, it works identically as when using GPIO 84 &85; the serial data exchange completes successfully, the menu is displayed, and attempt to run DFU CPU1 causes an immediate NACK error.

When you say "SCI peripheral on the F28377xD isn't configured correctly", do you mean in software or board hardware implementation? To my knowledge the only change needed to switch between the GPIO pairs is the SCI_BOOT or SCI_BOOT_ALTERNATE parameter passed to GetFunction(). Are there other places in F2837xD_sci_flash_kernels that need to be changed? Are there other places where configuration changes should be made?

Hi Thomas,

We'll take a look at this and get back to you within the next day. 

Charles

Thomas Cox said:

When you say "SCI peripheral on the F28377xD isn't configured correctly", do you mean in software or board hardware implementation? To my knowledge the only change needed to switch between the GPIO pairs is the SCI_BOOT or SCI_BOOT_ALTERNATE parameter passed to GetFunction(). Are there other places in F2837xD_sci_flash_kernels that need to be changed? Are there other places where configuration changes should be made?

Yes, the SCI peripheral for the f2837xD is configurable through the software implementation, where you can switch from SCI_BOOT to SCI_BOOT_ALTERNATE. For the F2837xD_sci_flash_kernels file, nothing else needs to be changed for the example.

Charles - Thanks for for confirming my analysis of software configuration for selecting different GPIO pairs for SCI-A communications when programming flash with the sci_flash_kernels program. The question still remains unanswered, if SCI communications is apparently occurring during download of the kernel, why does requesting DFU-CPU1 cause a NACK error? What is going wrong, and what can I do to execute the command successfully?

Thomas,

Sorry that you have been struggling with this issue for a number of weeks now. I was pulled in by Anu and Charles to assist you with this issue, and while I claim no expertise in this area, I will certainly try to help you to the best of my ability.

So I read through the message chain, and my understanding of the summary of the issue is as follows:

1. You are seeing issues (NACK error etc.) when you try to use SCI Boot mode on the F2837x and try to download the Flash kernel. The menu is appearing, but once you hit a DFU CPU1 command, the error appears.

2. The issues occur regardless of whether you use GPIO 84/85 or 28/29. In each case, you are rebuilding the Flash kernel accordingly, to support the required GPIO configuration. In the former case, since the F2837xD ControlCard does not support using the USB connector, you are probably connecting to the GPIO pins directly on the board. In the latter case, you are probably using the USB connector.

3. Admittedly, we have never tried using GPIO 84/85 for SCI Boot with the F2837x ControlCard, for the reasons mentioned above. However, we have definitely tried it with the 28/29 combination successfully. Given that this is not the default mode, a few additional steps are needed. The main reason for this is because we need to set the BMODE field appropriately. I do realize you ultimately need things to work with GPIO 84/85, but could you give this a shot and see if your setup with GPIO 28/29 works?

Thanks,

Sira

Sira - Your instructions are unclear in two ways. 1) the image of the text comes out very small, and is fuzzy when I try to open it in a new tab and zoom in. Can you tell me the the TI document and page number so I can read it in a PDF? 2) Step 4 sounds like I need  to run the CCS debugger to change the contents of the BOOTCTRL register in EMUBOOTCTRL. If so, what program am I debugging? Is it F2837xD_sci_flash_kernels?

I am trying to establish a procedure that does not require changes to OTP locations, and does not have to use the CCS debugger. Just plug in and run. Is there another way to change the BOOTCTRL register in EMUBOOTCTRL programmatically without running the debugger?  Can that logic be added early in execution of the sci_flash_kernels program?

Thomas,

1. sprabv4, page 20. Look at the answer to the question "With the ControlCARD, I cannot download the SCI Flash Kernel to RAM in SCI Boot, what steps should I take to do so?"

2. Correct, this is the idea, we are trying to set the BMODE field of the EMUBOOTCTRL register. In this step, you don't necessarily have to be debugging any executable within CCS.

3. I understand. My goal is to see if you can get your setup working with GPIOs 28/29 like we do. Once we do that, we can turn our attention to GPIOs 84/85 (which is the default mode and does not require any special settings).

Thanks,

Sira

I have configured switches on the controlCARD per steps 1-3. Power to the boards is applied through the power jack on the DOCK card. SCI-A communications is via the USB port and XDS100v2 interface. When I start Run/Debug, I get the error message Error connecting to the target (Error -2131 @ 0x0). What can I be doing wrong?

Thomas, I will try this tomorrow on a F28379D CC and get back to you with a clearer screenshot of what is expected.

Thanks,

Sira

Sira  - regarding my last message, I reviewed my configuration this morning and found that I had SW1:1 position 1 set incorrectly. Fixing that got rid of the error connecting to target. Console contents now look like figure 6.1 in the document. But when I attempt option 1 DFU CPU1 from the menu, I still get "NACK error with sending the function packet".

Hi Thomas,

Have you tried putting breakpoints within the SCI_GetFunction.c file? Within this file, the function SCI_GetPacket can determine what is being sent incorrectly from the host, either the checksum or data may contain errors. Breakpoints can be placed at lines 604, 622, and 627 within the file to see what triggers the NACK error. Load symbols for the kernel in CCS, then set breakpoints at those locations, and try running the DFU command. 

Regards,

Charles

Charles - Thanks for the debug info. I am calling F2837xD_sci_flash_kernels by calling serial_flash_programmer.exe and passing parameters. How do I do that, and run sci_flash_kernels in the CCS debugger?

Thomas,

In order to examine the host behavior, follow these steps:

1. Open CCS with the project folder
2. View and launch the target configuration file
3. In the debug window, right click CPU1 and connect to target
4. Under the view tab, click the memory browser window and input address 0xD00. At this address, type the hex value 815A.
5. In the toolbar pane, click the CPU Reset button for CPU and then press resume for CPU1.
6. Open the command prompt and navigate to the folder which contains your flash kernel (alt version) and application hex files (.txt), as well as the serial_flash_programmer.exe
7. Enter this line, changing numbers for your specific COM port (ex. COM6, which can be found in Ports within device manager)
serial_flash_programmer.exe -d f2837xD -k F2837xD_sci_flash_kernels_cpu01_alt.txt -a blinky_dc_cpu01.txt -b 9600 -p COM -v
8. Allow the files to download to the device. Once they have downloaded, return to CCS, pause the program and within the toolbar pane click the load icon and load the flash kernel program .out symbols for the device by browsing projects.
9. View the SCI_GetFunction.c file and at lines 604, 622, and 627 place breakpoints to view for NACK error
10. Press resume within CCS for CPU1. Return to the command prompt and press 1 for DFU CPU1.

If you have Microsoft Visual Studio as an option, you can also pass the parameters (ex. -d f2837xD -k F2837xD_sci_flash_kernels_cpu01_alt.txt -a blinky_dc_cpu01.txt -b 9600 -p COM12 -v) into the serial_flash_programmer SLN file. You would have to go to Debug > serial_flash_programmer Properties > Configuration Properties > Debugging, where the command arguments line is.

Regards,

Charles

Charles - Thanks for the excellent instructions for linking a CCS debug session to an EXE file running from a command window.

I followed your instructions. All went well until the final step. The message "NACK Error with sending the function Packet..." still occurs, but none of the 3 breakpoints trip.

It is probably not relevant, but it might help to find the source of the NACK to know that that message is followed by "downloading .\blinky_cpu01.txt to device...  Checksum does not match... Please press Ctrl-C to abort".

Hi Thomas,

Let me look into this. I believe it has something to do with how the pausing is setup for the steps provided. The CPU1 needs to be paused before the DFU CPU1 command is executed. Will also check into the checksum message.

Charles

Thomas,

Does this error occur when you try to perform another command operation other than DFU CPU1? 

Charles

Charles: I performed the test you requested. Instead of DFU CPU1 I selected option 3 Erase CPU1. I selected sector C followed by 0 to end the selection list. The immediate response was the same as before with the DFU CPU1 selection: "NACK Error with sending the function Packet...". That was followed by:

ERROR header 41b
ERROR checksum
Expected 7
Recieved 0
ERROR footer 700
ERROR with Packet Command!
ERROR Status: Not Recognized Error
ERROR Address: 0xcccccccc
Error not recognized
Please refer to the Flash API documentation for further explanation of the error.
FMSTAT Register contents: cccccccc

Because the error list says "refer to the Flash API documentation", you should know that I am running from a batch file that contains:

C:\ti\C2000\C2000Ware_4_01_00_00\utilities\flash_programmers\serial_flash_programmer\serial_flash_programmer.exe ^
    -d f2837xD ^
    -b 9600 ^
    -k ..\targetConfigs\F2837xD_sci_flash_kernels_alt_cpu01.txt^
    -a .\%1.hex ^
    -p COM%2 ^
    -v

where I have entered "blinky_cpu01.hex" from the CPU1_FLASH build configuration for parameter 1 and "4" for parameter 2.

I wondered if there are inherent differences between the blinky_cpu1 project and the blinky_dc_cpu1 project that could be causing the failure. I changed the link cmd file to use ALIGN(16) instead of ALIGN(8), and changed the flash location from sector B to sector C. I built the blinky_dc_cpu1 project in the CPU1_FLASH_STANDALONE build configuration and used it instead. It gave the same error messages for menu selections DFU CPU1 and Erase CPU1.

Hi Thomas,

What revision is your controlCard? Also what is the wire length between the host and the target, as this might affect transmission. 

In addition, could you try running the sci_loopback and sci_echoback examples located here: C:\ti\c2000\C2000Ware_4_01_00_00\device_support\f2837xd\examples\cpu1

to verify SCI functionality.

Charles

The controlCARD is stamped as R1.3.

I have been connecting to the USB port from the controlCARD to the Windows 10 host through a USB extender cable. This morning I tried a direct connection using the USB cable that came with the controlCARD. The sci_loopback and sci_echoback programs work perfectly in both configurations. So cable length does not appear to be a factor.

However, for serial_flash_programmer, I discovered that I had been specifying the COM port for the mouse, NOT the COM port for SCIA on the controCARD. So it is obvious why attempts by the kernel to use the SCI port failed. It is odd that serial-flash_programmer seemed to think it had downloaded the kernel successfully and presented the menu.

Now I seem to have a new failure. The attempt to download the kernel from serial_flash_programmer using the COM port associated with the USB - FTDI interface stalls at "attempting autobaud to load kernel". Behavior is the same regardless of cable configuration.

Hi Thomas,

I'm glad you're able to resolve the COM port issue. Can you provide the exact steps you're taking getting to the "attempting autobaud to load kernel" prompt?

Thanks,

Charles

I supplied the batch file in my previous reply. The parameters I am passing to serial_flash_programmer resolve to blinky_cpu01.hex for the image to be programmed, and COM13 for the Windows serial port to the USB port on the controlCARD. The response from serial_flash_programmer is:

getting comm state
building comm DCB
adjusting port settings

calling f021_DownloadKernel CPU1 Kernel
Downloading ..\targetConfigs\F2837xD_sci_flash_kernels_alt_cpu01.txt to device...

Attempting autobaud to load kernel...

And there it sits.

Hi Thomas,

I see. Is the blinky file you're using with the extension .hex? I have used .txt in order to confirm the image in the example. I would also recommend to use blinky_dc_cpu01.txt file instead of blinky_cpu01.hex.  Also, do you have another controlCard to use to see if it is a hardware issue?

Charles

The flashable file content which is produced by output of hex2000.exe is identical whether a .hex or .txt file type extension is used. Does the filename extension really affect the flash programming result?

I have tried both blinky_cpu01 and blinky_dc_cpu01. Both behave identically re: errors produced by serial_flash_programmer.

We do have a 2nd controlCARD. I configured it to program flash over the USB port. I tried serial_flash_programmer on both blinky_cpu01 and blinky_dc_cpu01. Results were identical to the first controlCARD.

Thomas,

That is correct on the file extensions for .hex or .txt file type, was just comparing possible differences in our setup. If both controlCard's have the same results, then it makes it less likely to be hardware related. I have messaged you if you would like to set up a private call to address the issue.

Charles

Charles - Thanks again for your help. I repeated the flash programming this afternoon for the alt flavor using GPIO 28 & 29 for SCI-A on the controlCARD. This time I used the CCS debugger to set location 0x0D00 for SCI boot option 2 to 0x815A. I then ran the batch file from the command window. All steps including DFU CPU1 appeared to work correctly. I then did a menu option 5 - Verify CPU1. That failed with the following message.

Bit rate /s of transfer was: 6997.561523
Application load successful!
Done waiting for application to download and boot...
SUCCESS of Command
ERROR Status: VERIFY_ERROR
ERROR Address: 0x8201c
Flash API Error: Failure
Please refer to the Flash API documentation for further explanation of the error.
FMSTAT Register contents: 00

In addition, when I cycled power after setting SW1 for boot from flash on the controlCARD, the LED did not blink. 

I tried using SCI boot option 1 with GPIO 84 & 85. Download of the kernel appeared to work fine. When I tried DFU CPU1 from the menu, I got

calling f021_SendPacket

NACK Error with sending the Function Packet... Please press Ctrl-C to abort.Downloading .\blinky_cpu01.hex to device...

Checksum does not match... Please press Ctrl-C to abort.

The COM port selection for the SCI connection to the controlCARD is correct this time. It seems there is a step I am skipping to make the kernel operate correctly for SCI boot option 1, using the default GPIO pair.

Hi Thomas,

It's great that you got DFU CPU1 to work via the GPIO 28/29 pins. When you press DFU CPU1 in this setup, what is the entry point address that is stated?

The VERIFY_ERROR status indicates that it failed trying to verify the program in Flash Sector B (address 0x8201c). Is this using the default blinky linker command file or the modified one for Flash Sector C? It's possible that you programmed one section and it is trying to verify a section not programmed. I would also ensure the file is aligned to 128-bit boundaries ( ALIGN(8) ). Also, could you see if a section is being mapped to RAM and not Flash memory?

For SW1, I have confirmed download operation with SCI/WAIT boot mode (left switch up, right switch down). When putting SW1 in Flash boot mode (both switches up), the LED blinks. 

For the SCI Boot Option 1 w/ GPIO 84/85 pins, are you using the HSEC docket to reach these pins physically as well?

Charles

Charles - Thanks for your suggestions. I'll get back to you on this in a few days. A couple of other projects have taken priority for the short term.

Thomas,

That's good to hear. Looking forward to your next response.

Thanks,

Charles