TMS320F28069: In Disassembly window cant able to Step into (forward) for Flash

Robin,

What is the program entry point for your application?

Regards,

Ozino

here it is

thanks

Robin

Robin,

Can you go to the Tools->Debugger Options->Auto-Run and Launch options from the toolbar?  It should bring up the below dialog box:

You'll want to make sure the box circled is unchecked.  In your above example I think the code has already run past the Boot.asm code due to this.

Once you've deselected this after you load your program, and click reset you will go through the same boot flow as a device w/o an emulation connection(and the EMU BOOT should be taken as you have set it).

Best,
Matthew

hello Mathhew

Thank you so much for your valuable reply, I have tried in that way too but still it is same infinite for loop (between line 419 to 428).

Thanks

Robin

Hello Matthew

This isn't work , still I am having the same error, can you please suggest different approach, I also don't know what is the reason to stuck in the infinite for loop? because in simple debug and run there is no issue I see but in flash only have problems.

Thanks

Robin

Robin,

I'm not sure I understand the issue correctly, the code snippet you have shown is inside the main() function in your code with an infinite for loop that will remain there forever.  At this point the code will have executed past the boot code, and any initialization.

Now, the PWM ISRs should continue to trigger, and you should see the code periodically jump to those ISR routines.  Is this the issue, that the ISRs don't trigger?  I'm not sure how that is related to the flash memory aspect as well.

Best,

Matthew

Matthew,

I follow this method for flash operation "">www.youtube.com/watch You will notice that we need to do single-step forwarding from the current location (from Disassembly window) to the beginning of codestartbranch.asm, which is a link to cmd file (for the boot to flash operation). But the problem occurs at the "infinite for loop" it won't allow me to reach codestartbranch.asm file. My ultimate goal is to store the code permanently into a control card.

Best,

Robin

Robin,

I believe that if you are in the infinite loop you have already executed code start branch, and gone through to your main function.  From your screenshot the infinite loop is present in your C code and that is where the CPU is stuck.  I think the point of the video was just to show the execution that took place in the ROM, and then the branch to flash memory.

The screenshot is showing that the code(in the dis-assembly window) is at address 0x3F638A, which is in Flash sector A 0x3F4000-0x3F7FFF.  So you have already programmed the code to flash and are executing from flash at the point you have stopped CCS.

Code Start Branch would have happened much earlier, before main() was called.  Unless we uncheck the boxes as I mentioned before, CCS will automatically goto main() after a program has been loaded(and always skip Code Start Branch).

Best,

Matthew

Thank you for your reply, I am at the flash address (between 0x3F4000 to  0x3F7FFF), then I run the code then press terminate, after that I unplug everything and plugin it again, I was expecting it should be in flash but I didn't get any output it means it is not going to flash. Can you please guide me the entire process for flash so I can understand that where I am making mistake.

Thanks

Robin

Robin,

Can you verify that the boot pins are set to GetMode per the below table(default action of GetMode is boot to flash).

Best,

Matthew

Hello Mathhew

GPIO 34 sets high, but I don't see GPIO 34 in the code, about TRST I have attached the screenshot of the schematic.

Thanks

Robin

Robin,

You will need a 2.2k-10kOhm resistor to VDDIO on GPIO34 and GPIO37.  GPIO37 also function as TDO(JTAG signal) so you'll need to find that signal on your schematic.  TRSTn should have a 2.2k-10kOhm resistor to VSS, so that it is kept in reset when the debug probe is not attached.

From the above picture, I'm not seeing the pull up resistor on GPIO34 either.  Are you using a TI HW like launchpad or controlCARD or is this a custom PCB?

Best,

Matthew

Thank you, Matthew, for your reply; yes, It's the customer's PCB; it seems I think I need to make some hardware changes. Can I use Uniflash software for the stand-alone operation? Without changing any hardware change, as you mentioned?

Thanks

Robin

Robin,

Yes, uniflash will program through the JTAG connection and does not require a bootloader.

Best,

Matthew

MatthewPate said:

You will need a 2.2k-10kOhm resistor to VDDIO on GPIO34 and GPIO37.  GPIO37 also function as TDO(JTAG signal) so you'll need to find that signal on your schematic.  TRSTn should have a 2.2k-10kOhm resistor to VSS, so that it is kept in reset when the debug probe is not attached.

In our schematic, GPIO 34, 37(TDO) are indeed set to 1,  and TRSTN pulled low. So these are in the 'get mode'. 

Pl, see attached screenshot of the actions we took to write to  Fash.

A read-back using UNIFLASH, we see the flash was not accessed( all addresses contain FFFF- see screenshot)

We would expect to see the code written in the Flash with a check-sum provided by CCS

What do we have to do to successfully access the Flash & run in stand-alone mode?

Any help will be highly appreciated.

 

Thanks

Robin

 

Robin,

Can you send me the .map file that is generated when you compile the project?  I'd like to verify the expected flash regions that should get populated.  This should exist in our project directory post compile.

Best,

Matthew

Sure, I have tried to upload the .map file but it doesn't allow me. I converted that into the .doc format.TMS320C2000 Linker PC v20 MAP file.docx

Thanks

Robin

Robin,

I've gotten a bit behind today, I'll post another reply later tonight US time with my analysis.  Appreciate your patience here.

Best,

Matthew

No worries Matthew, Take your time, appreciate for letting me know.

Thanks

Rg

Robin,

Please take a look at address spaces 0x3F0000(Sector D) and 0x3F6000(Sector A) as these contain the program code from your project.  In the case of the code in Sector D, this is defined as run from RAM(after a copy function is ran) for speed reasons, so you should see this code duplicated at RAM address 0x8000.

The only flash that is assigned to data space is Sector B(0x3F4000), which is empty.  If you want to have some type of data table that is updated/allocate to this space during run time, then you would need to invoke the Flash API to write this data as it is generated.

If this space was intended to house a data table that is load time initialized then we would need to define a #pragma which would generate a linker directive to load code to this space for use later in program execution.

Let me know if the above is addressing your concern with CCS loading the flash correctly.

Best,

Matthew