CCS/TMS320F28035: tms320f28035

Yoonseok,
I would recommend looking at this example for the F2803x in C2000 Ware: C:\ti\c2000\C2000Ware_1_00_06_00\device_support\f2803x\examples\c28\flash_f28035

This takes one of the ePWM examples that was orginally built to run from RAM and by modifying the linker file it is built to load to flash then run accordingly. You can look at the top comments as to what was touched as well as look at the .cmd file and compare it to the one you have that works for RAM execution and note the differences.

Let me know if you are able to get your example working after looking at the above.

Best,
Matthew

Wanted to follow back up to see if you had some success with the above suggestion.

Best,
Matthew

Hi, matt

I am so appreciated for your answer to my question and sorry for this late reply to you.

I've checked the TI example you've suggested to me and applied this on my App code but it seems not to make up the issue

the malfunction still exists.

To solve my issue, I think I have to let you know my situation and test environment.

our team has developed the prototype of a circuit board for a device and We've embedded TMS320F28035 as the main MCU.

Execution an application code out of RAM of the embedded MCU on the prototype worked very well no matter which App code was loaded.

but when I tried executing my application code for our project out of FLASH of the MCU, the Issue happened.

The light size App code such as 'ePWM Updown' which is a simple TI example code worked properly from FLASH of the MCU embedded on the prototype, but my App code which sets the operations of various modules such as 'ePWM', 'eQEP', SCI and 'I2C' didn't work as intended.

To find out the solution on the issue that happened on the prototype with my app code,
I tried loading it into a development kit.

but the same malfunction also happened on the kit.

however, the funny thing is that there was the moment that my App code worked very well from FLASH of MCU embedded on the development kit during 100 trillion tries. and when it started to operate very well, it kept the intended operation successfully whenever I tried the execution.

the issue seemed to be solved out.

As soon as I checked the operation went well on every try, I tried running my app code again on the prototype.

but the malfunction happened again on the prototype.

As soon as I noticed the malfunction, I detached my emulator from the prototype and I tried loading my code into FLASH of MCU embedded on the development kit again with the emulator. however, the same malfunction happened on the kit although it had operated successfully before I tried loading and executing my application code out of FLASH of MCU on the prototype.

It looked like Zombie virus was contained in the prototype and the development kit was infected by it through the emulator. hahaha....

so now I am assuming that the prototype seems to have a bad effect on the registers relevant to JTAG or something related to an emulator.

could you give any suggestion on that?

and where can I see the reference guide document about JTAG and its operation?

I hope that I don't make you confused while you read this email. if so, please let me know. 

thank you so much for your sincere support and hospitality.

 

 

Would it be possible to confirm that your programmation was successful on both your prototype and the dev kit? What I mean by this is after you program the flash(are you using programmer built into CCS or something else) read the contents out and make sure they match your intended image.
You can export large amounts of memory in CCS by using the Save Memory under the "Tools" menu item. There are alot of different formats, so choose the one that matches whatever format your source is in.
If we can determine that the flash is getting programmed correctly we can debug the more functional aspects of the code.

Best,
Matthew

Hey Matt! 

your suggestion and the TI example was the solution of my code. 

my app code has been running very well on both the development kit and the prototype.

I don't know exactly what matter was when I applied the example source on my code and ran it on my first try.

I guess It was because I had forced MCU many times to get it run with the non-proper code for flash running

before I applied the example code.

I could solve it by writing the preprocessor "#pragma CODE_SECTION(epwm1_isr, "ramfuncs")" on the top of

source of main.c and memcpy((uint16_t *)&RamfuncsRunStart,(uint16_t *)&RamfuncsLoadStart, (unsigned

long)&RamfuncsLoadSize); in main function. and I also checked the allocation of the cmd file is same as the one in TI example

code you had suggested me for checking.

and also I used "InitFlash()" function for high performance of flash running.

I thought the Preprocessor for allocating the function 'InitFlash' to the user output section 'Ramfuncs' doesn't need to be written

one more time on main.c because it is already written in 'SysCtrl.c.'

but I am so curious what the main issue with my code is when it is executed only out of the FLASH?

I don't think my code is not that long and complicated. all I have done so far with my code is just setting the

register for the use of MCU modules on my purpose such as, 'ePWM, eQEP, I2C, SCI, and ADC.

moreover, I set the register to use the 'ePWM' Interrupt mode which operates on every 100us.

(that interrupt ISR is the function which I get copied to SARAM from FLASH. after I did it, my code runs very well like magic!)

and I have noticed the code copy can be accomplished successfully by writing memcpy function. what happens in detail

if I only write CODE_SECTION preprocessor without the memcpy function written? 

without memcpy, It looked like the code can also run but what I notice was a Unit16 global variable I declare to

get continuous data of position counter from eQEP at the ISR seemed not to get any values from eQEP.

I also noticed that ISR can be entered without the proper set of the memcpy or CODE SECTION preprocessor.

thanks, MATT so much for your effort on helping me out  and sincere reply. It is my great pleasure that I get the chance to be

helped by you online. 

In terms of memcopy function and the code working with/without it depends on if you have configured that code to RUN from a different space than the LOAD.  This is only something done when code is loaded to the flash, but you want to run from SRAM to get better speed(the RAM is 0 waitstates, while the flash is 3 WS at 60MHz).

So, if there is not a concern with speed, you can execute the program out of flash and not copy to SRAM.  In this case there would be no RUN address in your linker(.cmd) file.

In terms of the QEP value being incorrect, I'm not really sure how that can happen.  Certainly if executing from flash it will be slower to execute, but the value should still be there.  

I would use a watch window with the QEP registers in view to look at the contents while you are executing to make sure the QEP itself is behaving in the correct way.

Best,

Matthew