TMS320F28035: TMS320F28035

Where did you read that AdcConversion() would only work from RAM? Generally, running a function from RAM is a decision that's made for speed or for making the number of execution cycles more deterministic, since Flash can have wait states, caching, prefetching, etc...For example, the underlying function for DELAY_US() is run from RAM so that the number of cycles per loop will be the most precise. We also run InitFlash from RAM since you shouldn't try to execute from Flash while you're configuring Flash settings.

Of course there is the exception for CLA code, which can only be executed from RAM.

One quick way to find out all the functions in the F2803x device support folder in controlSUITE that we suggest you run from RAM, would be to do a quick search of the directory for "ramfuncs"--that should find all the #pragma CODE_SECTION lines for putting the functions in RAM.

Whitney

Dear Whitney

Thanks for the support.   I am working on a new project based TM320F28035.  I started working on the experimenter kit and tried to execute adc example from flash and it was not working.  I posted in the forum I got an advice to run AdcConversion() from RAM( see the link below).  Example works only after running AdcConversion() from RAM.

"https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1121371/tms320f28035-tms320f28035/4160220#4160220"

Not sure how to search ramfuncs inside files.

Regards,

Ramesh

Ramesh,

Understood. I'll talk to Matt and see if we need to file a bug to get a #pragma CODE_SECTION added to the code to avoid this confusion in the future.

Ramesh Muruganantham said:

Not sure how to search ramfuncs inside files.

A lot of code editing applications (like Visual Studio Code, etc...) have file search options. Even CCS has a search option (View -> Other..., find Search). It would look something like this:

Whitney

Dear Whitney,

Thank you very much.  One more question - Why should we run AdcConversion() from RAM?  Is it because of the following lines

while( AdcRegs.ADCSOCFLG1.bit.SOC9 == 1 )
{

}

Could you confirm?

Regards,

Ramesh

I wasn't able to reproduce the issue, so I couldn't observe the the exact behavior, but I can see where it could be timing sensitive. My guess is that since the interrupts aren't in in continuous mode, if the interrupts aren't cleared within a certain window, the interrupt overflow flags may be getting set (you can check the ADCINTOVF registers to see if that seems to be the case).

Whitney

I checked  the ADCINTOVF register and it is read as : 0x0002  which indicates the Overflow flag is set.  Additionally I noticed  the Program counter is looping between the following addresses - 3f61D9, 3f61DC, 3f61DD.  Do you see any clue from this?

Regards,

Ramesh

Those addresses look like boot ROM addresses. You seem to be getting a reset of some kind or maybe an unexpected interrupt that's that's sending you to the boot ROM default ISR. You can try loading the ROM symbols to see what function it is. They are in:

<c2000ware install dir>\libraries\boot_rom\f2803x\v1_0\rom_sources\Release\TMS320x2803x_boot_rom_Gold_V1.out

Whitney

I checked the .map file and it seems to be flash RAM where user code is executed.  This specific address fall within AdcConversion() function.

page address name
---- ------- ----
0 00008000 _DSP28x_usDelay
0 00008000 _RamfuncsRunStart
0 003f0000 _RamfuncsLoadStart
0 003f6000 .text
0 003f6000 _InitAdc
0 003f6000 ___text__
0 003f601f _InitAdcAio
0 003f6041 _AdcOffsetSelfCal
0 003f6068 _AdcChanSelect
0 003f60dd _AdcConversion
0 003f622e _INT13_ISR

Sorry--you're right. Boot ROM starts at 0x3FE000. 0x3F6xxx are valid flash addresses. You can't tell what lines in the C code those 3f61D9, 3f61DC, 3f61DD addresses correspond to? What does the disassembly look like?

Whitney

How to check disassembly?

Regards,

Ramesh

I could generate the .lst file.  My observation is it is stuck in the following lines

while (AdcRegs.ADCINTFLG.bit.ADCINT2 == 0)
{

}

ADCINTFLG is read as 00.

part of .map file below

page address name
---- ------- ----
0 00008000 _DSP28x_usDelay
0 00008000 _RamfuncsRunStart
0 003f0000 _RamfuncsLoadStart
0 003f6000 .text
0 003f6000 _InitAdc
0 003f6000 ___text__
0 003f601f _InitAdcAio
0 003f6041 _AdcOffsetSelfCal
0 003f6068 _AdcChanSelect
0 003f60dd _AdcConversion
0 003f622e _INT13_ISR
0 003f6233 _INT14_ISR
0 003f6238 _DATALOG_ISR
0 003f623d _RTOSINT_ISR

Part of .lst  of   DSP2803x_Adc.c below

800 .dwpsn file "C:/ti/C2000Ware_4_01_00_00/device_support/f2803x/common/source/DSP2803x_Adc.c",line 333
801 000001d4 761F! MOVW DP,#_AdcResult+7 ; [CPU_ARAU]
000001d5 0000
802 000001d6 0E07! MOVU ACC,@$BLOCKED(_AdcResult)+7 ; [CPU_ALU] |333|
803 000001d7 0742 ADDL ACC,*-SP[2] ; [CPU_ALU] |333|
804 000001d8 1E42 MOVL *-SP[2],ACC ; [CPU_ALU] |333|
805 .dwpsn file "C:/ti/C2000Ware_4_01_00_00/device_support/f2803x/common/source/DSP2803x_Adc.c",line 338
806 000001d9 $C$L3:
807 .dwpsn file "C:/ti/C2000Ware_4_01_00_00/device_support/f2803x/common/source/DSP2803x_Adc.c",line 338
808 000001d9 761F! MOVW DP,#_AdcRegs+4 ; [CPU_ARAU]
000001da 0000
809 000001db 4104! TBIT @$BLOCKED(_AdcRegs)+4,#1 ; [CPU_ALU] |338|
810 000001dc 6CFD B $C$L3,NTC ; [CPU_ALU] |338|
811 ; branchcc occurs ; [] |338|
812 .dwpsn file "C:/ti/C2000Ware_4_01_00_00/device_support/f2803x/common/source/DSP2803x_Adc.c",line 343
813 000001dd 1A05! OR @$BLOCKED(_AdcRegs)+5,#0x0002 ; [CPU_ALU] |343|

Regards,

Ramesh

I was referring to the debugger Disassembly window--in the Debug perspective go to View -> Disassembly to pull it up. Your next post does answer my question though.

When the ADC interrupt is not in continuous mode, no further interrupt pulses are generated until ADCINTFLG is cleared. Instead the ADCINTOVF flag is set. So my suspicion is that ADCINTFLG isn't being cleared in time for the next EOC event that wants to set it, so it's getting an ADCINTOVF event and no interrupt pulse is generated to start the next round of conversions. Even though ADCINTFLG is eventually cleared, it happens too late.

I'm not sure if enabling continuous mode would solve the issue, but you could try it.

Whitney