SCI boot for TMS320F2837xD controlCARD

Hi vesgine,

1. What is meant is that you can set the GPIO boot pins such that the device will use Get Mode.  Next, don't do anything to the OTP.  As a result, the device will boot to FLASH.  At the beginning of the flash code (perhaps in main), you can determine what boot mode you want and under what conditions.  Your code in flash will then call one of the boot ROM functions that exists in ROM.  You can do this by potentially jumping to a specific address.  The Boot ROM source can be found at the below:
\controlSUITE\libs\utilities\boot_rom\

2. Yes, EMU_BMODE = 0x81.  I understand your question, but am not aware of the answer.   I will ask another member of my team to respond.  Note that we only recommend this option for validation.  In an end application, we don't want TRSTn to be high during operation when an emulator is not connected.


Thank you,
Brett

yes for #2, the EMU_BMODE is supposed to be set up either via GEL script or from Memory window. It is for debug only.

and I agree with what Brett suggested for #1.

Hope this helps

Best Regards
Santosh Athuru

Hi vesgine,

1. I think it's best to ask what you want to do when you boot from SCI.  Are you wanting to program the flash or use the SCI bootloader directly (so that it could be used with something like C2Prog)?
   https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/514556/1872465
   
   If the bootloader code is sufficient for you (just with GPIO28 & GPIO29), you may be able to jump to the bootloader address.  Or it may be easier to pull the relevant bootloader code that you wish to use into your project.
   
   
2. Yes, as long as the C2000 is the only thing able to drive the pin, you should be fine.
   https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/518367/1887010

Thank you,
Brett

Hi, Brett

SCI boot from application for 28335 was verified before. Now I try to implement it on 28379D, but it failed.

The platform is F2837x controlCARD R1.3 with F28379D on it. The main code is shown as below.

Because the default SCI boot option use GPIO84 and GPIO85 and the controlCARD use GPIO28 and GPIO29 as SCI-A pins, the parameter 0xF0 is used here when calling SCI_Boot function.

Firstly, I run the code above and enable a breakpoint at line 27. Then I start C2Prog and try to program the FLASH. However, the program doesn’t stop at the breakpoint but entry a error place shown below(Line 473).

The C2Prog give the message below.

Then I step into the SCI_Boot function again. The program can run to the end of this function(line148) with EntryAddr equals to 0 as shown below.

It seems that the SCI_Boot function works well. But the error occurred when the program branched to point 0x0 and started from there. So what’s the problem?

Besides, there are two version of boot rom for F2837x in the folder of C:\ti\controlSUITE\libs\utilities\boot_rom, namely F2837x_rev0 and F2837x_revb. What’s the differences between them?

Hi, Chris

I couldn't insert a return instruction nor a breakpoint into the c1brom_itrap_isr. When the program stopped at "asm("ESTOP0")", the variable iTrap_addr equals to 0. At this time, the stack memory and disassembly info are shown below.

The project(blinky_cpu01) I used is come from controlSUIT except adding sci booting codes as I posted before. How to verify that everything was programmed in memory correctly and an illegal opcode? Is it poosible to do the same experiment to see how this happens? Because all the hardware and software are provided by TI and C2Prog(v1.7f-b5823) which are standard products. The CCS version is 6.1.1.00022 and compiler version is v6.4.9

Hi Vesgine,

On following point,

I couldn't insert a return instruction nor a breakpoint into the c1brom_itrap_isr.

This function is ROM function which is inside ROM (read only memory) so you can not insert any instruction here. For breakpoint, you need to use hardware breakpoint instead of software breakpoint. Please note that there are only two hardware breakpoints allowed so if you have already used them, you'll not be able to use further breakpoints. You need to remove other breakpoints to enable this one.

Regarding ITRAP, please check the value at address location 0x0 in CCS memory watch window (like you checked the stack value). Look like 0x0 address does not have proper code hence CPU is getting ITRAP.

Regards,

Vivek Singh

Hi, Vivek

The value at address location 0x0 is shown below.

I stepped into the function SCI_Boot() and found that the address 0x0 is returned by SCI_Boot() as shown below.

The LRETR instruction returns PRC register which is 0. Then the program jumps to address 0x0 and ITRAP occures.

Now I found out the reason of ITRAP. The CopyData() function of SCI_Boot is used to copy data from the C2Prog during bootloading. I stepped into this function and found that the DestAddr of the first block is 0x400 which is the start address of stack memory assigned by cmd unfortunately. This cause the stack memory is overwritten by C2Prog which leads to CPU getting ITRAP. So I changed the start address of stack memory from 0x400 to 0xB800. The bootloading is OK now. But the flash programming still failed with the info shown below.

I also stepped into the program and found that the SCI_Boot() function executed correctly with the return value equaled to 0x10122. The program then jumped to 0x10122 and never returned.

Hi, Vivek

I did another experiment using PC utility provided in controlSUITE in the device_support\~Utilities\serial_flash_programmer folder instead of C2Prog.

The command executed is "serial_flash_programmer.exe  -d f2837xD -k F2837xD_sci_flash_kernels_cpu01.txt -a blinky_cpu01.txt -p COM25 -b 9600".

It seems that the kernel is downloaded but not started as shown below.

According to sprabv4a, it should print the options to the screen to let the user to choose command like this.

Thanks Sal,

I might have misunderstood your previous statement. It was actually solution to the serial flash programmer issue and not to the C2Prog issue opened by the OP. I've been trying to get the C2Prog to work with the F2837xD controlCard and got stuck at 

I have contacted CodeSkin for the solution but any info here would be helpful. Thanks again...

I just got a reply from CodeSkin saying they don't have a solution to this (C2Prog working with F2837xD controlCard). I will make recommendations to use GPIO84/GPIO85 when we lay out the board. That should hopefully resolve the issue. Thanks.