TMS320F28335: eZdsp TMS320F28335

Maynard,

It is really difficult to find potential issues in source code snippets alone.  I recommend that we try to narrow down the focus to either a Project Build issue or an XINTF configuration issue.

For Project Build, see if the PC lands at the codestart section when Auto Run is disabled and the program is loaded to the device.

If this works, single-step through the code_start and InitExtMemIf sequence to see if the XINTF initialization is executing as intended.  Confirm that the desired values are being written to the registers.  The Memory browser window can be used to test the functionality of the XINTF interface throughout the sequence.

There is a simple run-from-flash example that can be used for reference if needed:  ~\C2000Ware_XXXX\device_support\f2833x\examples\flash_f28335\

-Tommy

Inii

Hello Tommy,

I have certainly caused some confusion in your team. Perhaps, I should make things straight first and hpe that you will accept my apology.

First, I am using the ezDsp F28335s for more than 10 years, now, even though lately I am also using the more advanced F28377D control card. All of them, though, through the MATLAB/Simulink-CCS platform. In other words, I have never actually used the CCS for debugging, memory reading, peripheral monitoring etc. Even though I have seen a couple of times how it works, on certain occasions and for very simple tasks. This has not stopped as from writing perfectly working applications for power converters, but this is another story.

Lately, a student of mine has created an FFT project that requires a great amount of memory. The programme, as expected, did not fit in the default ebss allocation that can be found in the original .cmd linker file. In the past, we have solved similar problems, easily, by joining some of the available memory blocks. This time, however, the application was memory exhaustive and we had no option but to utilize the external memory.

We have "enabled" the external memory by uncommenting the appropriate line in the gel file and we have amended the cmd, so that the linker allocates the external memory to the ebss (augmenting it in ZONE7P of Page 0 and deleting tag ZONE7D, altogether), like this 

ZONE7P:      origin=0x100000, length=0x1ffff

...

Sections{

...

.ebss:          >ZONE7P,    PAGE = 0

}

Then we checked the .map file and made sure that everything fits in place.

However, the code did not execute properly. In order to make things more transparent, we deleted everything except the code that just flashes the on-board led on and off at GPIO32 every few seconds. In simple words, we kept our code to the minimum to speed up compilation time, but maintained our aspiration to keep ebss in the external memory.

Reading carefully through the posts in the forum, we have discovered some advice from David Alter that this may have been caused by the way variables are used and updated in the ebss code. Therefore, I attempt to initialize the external memory in DSP2833x_CodeStartBranch.asm, using  InitExtMemIf following some instructions found here:

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/419126?External-memory-not-working-during-FLASH-F28335-

However, the instructions also point to the direction that peripherals (GPIOs, ADCs etc.) must also point to memory addresses that are available/appropriate. I believe this is done in the InitExtMemIf.asm file, that we have also included as additional source code in our Simulink file. However, we cannot understand how this can be done correctly (what is the logic behind the chosen addresses), even if we have noticed that the guy who accepted the advice from David Alter did change his original settings for the GPIOs addresses in there.

Sorry for the long intro, but now, that you have a better picture of our level of undestanding I believe you can also guide us better.

So, I believe the picture you have attached is from CCS, which allows users to set how the code is executed once loaded in the board. However, this is not something that I can find in my CCS 7.4, as CCS is used in the "background" during compilation of the Simulink Sketch. Back in CCS 3.3 days I could load the .out file directly and see all the C code produced. Now, it seams there is no such option, neither I know how to check if the PC lands at the codestart section when Auto Run is disabled and the program is loaded to the device.

Assuming I want to utilize most, if not all, of external memory for solely for our .ebss and not other purposes, could you please explain how this can be done in a step by step process, perhaps referring to and correcting the points I have mentioned above? What do we miss BEFORE we start checking if all these are done properly with CCS and step-by-step execution of the code? For example, do we have to set the way peripherals are accessed in InitExtMemIf  in some special way?

For this purpose, I have attached in this post:

1) the .map file where you can see how the code and data are placed in memory.

2) The DSP2833x_CodeStartBranch.asm that we have changed in order to load ebss variables properly (or we think that is the way it is used).

3) The InitExtMemIf  that has the peripheral settings.

Thank you,

Panagis

Panagis Vovos said:

However, the instructions also point to the direction that peripherals (GPIOs, ADCs etc.) must also point to memory addresses that are available/appropriate. I believe this is done in the InitExtMemIf.asm file, that we have also included as additional source code in our Simulink file. However, we cannot understand how this can be done correctly (what is the logic behind the chosen addresses), even if we have noticed that the guy who accepted the advice from David Alter did change his original settings for the GPIOs addresses in there.

Can you point me to these instructions?  I was not able to see any mention of address mapping in the thread that you referenced.

Panagis Vovos said:

Assuming I want to utilize most, if not all, of external memory for solely for our .ebss and not other purposes, could you please explain how this can be done in a step by step process, perhaps referring to and correcting the points I have mentioned above? What do we miss BEFORE we start checking if all these are done properly with CCS and step-by-step execution of the code? For example, do we have to set the way peripherals are accessed in InitExtMemIf  in some special way?

There is only the requirement to configure the XINTF that seems to be covered by the .asm.

Panagis Vovos said:

For this purpose, I have attached in this post

I am not able to see the attachments.

I noticed in the original attachment that the code seems to be using ZONE6, whereas the InitExtMemIf.asm was originally written for ZONE7.  Was the GPIO configuration updated for the switch from ZONE7 to ZONE6?

Thank you for your response.

The attachments can be found in the ticket-opening note of Maynard in the referenced .zip file. However, I will repeat them all here, with a better description.

>>Here<< you can find the linker file c28335ext.cmd. As you see, I first set  in PAGE 0 that ZONE7P: origin=0x100000, length=0x1ffff

I have named ZONE7P what I think covers both original ZONE7D and ZONE7P areas, so I have removed the definition of ZONE7D altogether from the linker file.

Then I ask .ebss to locate itself in ZONE7P by specifying in the same liker file: .ebss:          >  ZONE7P,              PAGE = 0

>>This<< is the Simulink File that just makes the led on-board the f28335 blink.

>>This<< is a screenshot of the Simulink schematic just in case you have some problem opening the original file.

When I start building the code for the board I can see in the Diagnostics Window:

"C:/PROGRA~3/MATLAB/SUPPOR~1/R2020b/3P778C~1.INS/TIC200~1.INS/TI-CGT~1.LTS/bin/cl2000" -z -IC:/PROGRA~3/MATLAB/SUPPOR~1/R2020b/3P778C~1.INS/TIC200~1.INS/TI-CGT~1.LTS/lib --stack_size=1024 --warn_sections --heap_size=1024 --reread_libs --rom_model --priority -m"MemTest28.map" --define F28335 --define PWM_DMAACCESS=0 --define BOOT_FROM_FLASH=0 --define BOOT_USING_BL=0 --output_file=../MemTest28.out MW_c28xx_board.obj MW_c28xx_csl.obj MemTest28.obj MemTest28_data.obj InitExtMemIf.obj c2833xBoard_Realtime_Support.obj MW_c28xGlobalInterrupts.obj DSP2833x_MemCopy.obj DSP2833x_CpuTimers.obj DSP2833x_DefaultIsr.obj DSP2833x_GlobalVariableDefs.obj DSP2833x_PieCtrl.obj DSP2833x_PieVect.obj DSP2833x_SysCtrl.obj DSP2833x_usDelay.obj DSP2833x_CodeStartBranch.obj DSP2833x_ADC_cal.obj DSP2833x_DMA.obj profiler_Support.obj MW_c28xGPIO.obj c2833xSchedulerTimer0.obj ert_main.obj C:/ti/controlSUITE/libs/math/FPUfastRTS/V100/lib/rts2800_fpu32_fast_supplement.lib C:/ProgramData/MATLAB/SupportPackages/R2020b/3P.instrset/tic2000codegentools.instrset/ti-cgt-c2000_18.12.2.LTS/lib/rts2800_fpu32.lib C:/ProgramData/MATLAB/SupportPackages/R2020b/toolbox/shared/supportpackages/tic2000/rtlib/IQmath_fpu32.lib C:/ProgramData/MATLAB/SupportPackages/R2020b/toolbox/target/supportpackages/tic2000/src/c2833xPeripherals.cmd C:/ProgramData/MATLAB/SupportPackages/R2020b/toolbox/target/supportpackages/tic2000/src/c28335ext.cmd

Which means that linker file c28335ext.cmd includes both >>InitExtMemIf.asm<< and >>DSP2833x_CodeStartBranch.asm<<, as it should. 

>>Here<< you can find the .out file created after compilation. By looking at the created .map file that you can check >>here<<, according to my understanding, the code for .ebss is placed at the correct memory space (Zone7P).

Just one thing in my case is not exactly as described in the original post. The initiating routine found in my CodeStartBranch is _c_int00, but the instructions refer to a shorter _c_int0. As you can see in the .map file: ENTRY POINT SYMBOL: "_c_int00" address: 00008562. Of course I can see my _c_int00 everywhere, instead of the _c_int0, that is why I used "_c_int00" after all, but I just want to make sure there is not an issue there.

Conclusion: the led on board the eZdsp F28335 does not blink and I guess the code does not run.

I hope things are a bit clearer,

Panagis

Dear Tommy,

Thank you for your valuable information. I have managed to make my program start from DSP2833x_CodeStartBranch.asm by adding -e"code_start" in the linker's argument in Simulink. I guessed, that it is just the same linker  with your approach called in the background, and it worked. I have also ticked the relevant "boot from flash (stand alone execution)" in the code generation tab, so the map file now looks like >>this<<.

 As you can see the new map file now has the whole package: ENTRY POINT SYMBOL: "code_start"  address: 0033fff6

and then later on, as you have suggested:

codestart
* 0 0033fff6 00000002
0033fff6 00000002 DSP2833x_CodeStartBranch.obj (codestart)

However, before I start my communication with Mathworks, please allow me to "tap" a little bit longer on your experience. What remains unclear to me is the first part of your reply: "Are you able to confirm the pinmux settings that are used in InitExtMemIf.asm? Please note that XZCS6 and XZCS7 are mapped to different GPIO pins so the GPIO configuration must be updated if you plan to use ZONE6, which falls into the address range that is defined in your CMD file".

I only use GPIO 32 in my Simulink (blinking led), which according to InitExtMemIf documentation can be found in GPBMUX1 Register bits 0-1. In the beginning of InitExtMemIf GPBMUX1 is set to be at the address 0x00006F96. What I can see in my .map file is that GpioCtrlRegs is located at 00006f80 of Page 1, which is a bit earlier than the 6F96. In the preliminary TMS320x2833x DSC External Interface reference guide I have found that "Many of the XINTF pins are MUXed with general purpose I/O. The GPIO mux registers must be configured for XINTF operation before you can use the XINTF."

Is this what you refer to? Or do you mean if I know a way to check if the register at 0x00006F96 changes during code execution? Where do I configure them? 

Any help would be highly appreciated, because my research at Mathworks brought little results on this field.

Thanks,

Panagis

Hello again Tommy,

I have done two things in order to be on the same page with you.

First, I studied the Tables for the Pinmux configuration. To the best of my understanding, I have to set the GPBMUX1 register in a value that GPIO 32, XZCS0n and XZCS7n is activated (Table 1-48). So, I have set in InitExtMemIf the respective address (0x00006F96) the value of 0xFFFFFFFC.

Second, I have installed CCS3.3, which is the only version that I know what I am doing, to be frank. There, I have loaded the .out file, so that I can monitor the execution of my code (even if it is created by Matlab) and memory. I can verify that the GPBMUX1 at 0x00006F96 is set to 0xFFFFFFFC. Also, I can see that the led does not blink, because the last bit of GPBDAT (0x00006FC8), which corresponds to GPIO32, remains constant and equal to 0. I can manually change that bit anytime and the led corresonfing to that GPIO switches on and off. Doesn't that mean that the GPBMUX1 is properly set, since that pin works as a GPIO pin? 

I have also compared the execution of the codes in two cases, when it is loaded on Zone6 and the default RAM location. By doing that by stepping in line-by line, I can confirm that the code is executed properly in both cases, all the way to the same loop call to the Simulink Function. But when .ebss is located on Zone6, it just doesn't change the last bit of GPBDAT so that the led blinks. If you look at my InitMemIf code >>here<<, I do not touch the other registers or maybe there is a conflict between XTIMING6 and XTIMING7. Is there a chance that I do not set OTHER MUX registers properly for XINTF (GPCMUX or even timers, for example) operation?

Thank you for your help,

Panagis

Panagis Vovos said:

First, I studied the Tables for the Pinmux configuration. To the best of my understanding, I have to set the GPBMUX1 register in a value that GPIO 32, XZCS0n and XZCS7n is activated (Table 1-48). So, I have set in InitExtMemIf the respective address (0x00006F96) the value of 0xFFFFFFFC.

Please confirm that you are configuring GPIO28 for XZCS6 in order to access the Zone 6 memory space.  I don't see this.

Panagis Vovos said:

I can manually change that bit anytime and the led corresonfing to that GPIO switches on and off. Doesn't that mean that the GPBMUX1 is properly set, since that pin works as a GPIO pin? 

Yes, if you can toggle the GPIO through the GPxDAT register, then that the means the GPIO configuration is correct.

Panagis Vovos said:

I have also compared the execution of the codes in two cases, when it is loaded on Zone6 and the default RAM location. By doing that by stepping in line-by line, I can confirm that the code is executed properly in both cases, all the way to the same loop call to the Simulink Function. But when .ebss is located on Zone6, it just doesn't change the last bit of GPBDAT so that the led blinks. If you look at my InitMemIf code >>here<<, I do not touch the other registers or maybe there is a conflict between XTIMING6 and XTIMING7. Is there a chance that I do not set OTHER MUX registers properly for XINTF (GPCMUX or even timers, for example) operation?

Each Zone uses independently configured timings. Are you able to write and read Zone 6 memory addresses through the CCS memory window after InitMemIf executes?  This is the way to validate the XINTF configuration.

Hello again,

"Please confirm that you are configuring GPIO28 for XZCS6 in order to access the Zone 6 memory space.  I don't see this."

I think I did that by setting both bits of the respective word register to 11. Those two lines in InitExtMemIf should do the job properly:

GPAMUX2_MSW .set 0xFF00

GPAMUX2_LSW .set 0x0000

Since, you mentioned that I attempted to specifically set GPIO28 for XZCS6, but noticed no difference, as it was expected:

GPAMUX2_MSW .set 0xA300
GPAMUX2_LSW .set 0x0000

"Are you able to write and read Zone 6 memory addresses through the CCS memory window after InitMemIf executes?  This is the way to validate the XINTF configuration."

No, as you can see below I could not write at those addresses. Is there any chance that simply address 0x100000 is not writable? The gel file says the opposite:

/* 0x100000 - 0x1fffff XINTF Zone 6 (Prog and Data) */
/* 0x200000 - 0x2fffff XINTF Zone 7 (Prog and Data */

When I changed the adress of commited external memory (named in  my linker file as ZONE7P) to 0x200000 (which IS Zone7) in the linker file, the light started blinking. I kept the length to 0x1ffff, as it was initially set, but I know that this extends beyond limits by half that size (0xffff):

ZONE7P:      origin=0x200000, length=0x1ffff

Now, I can write in address 0x200000 and beyond and the program works, as it looks properly loaded in memory: 

However, I lose half of the available external memory and I do need that size for the actual program. Why my initial linker setting does not work? Maybe that is the secret of my problems. Here is a reminder of how I have initially set it:

ZONE7P:      origin=0x100000, length=0x1ffff

According to my understanding ZONE7P is just a name and doesn't play any role. I could have named it as extern_mem or something else, and it should work as long as it extends in actual memory addresses. I think, thanks to you of course, I am getting closer.

Once more thank you for your guidance,

Panagis

Hello again,

Yes, I have located the schematic about ASRAM and XZCS7n in my >>eZdsp F28335 technical reference<<. However, a few pages earlier (pp. 2-6) there is Figure 2-3 "eZdsp F28335 Memory Space" that, according to the text above it, shows the memory map configuration of the eZdsp F28335. As you can see, there is clearly Zone 6 at External Memory XINTF, just above the memory space of Zone 7:

 In the previous page (2-5) that summarizes the eZdsp F28335 Memory specifications it clarifies that "... In addition 128K x 16 off-chip SRAM is provided", and in "Hardware Features" at the very beginning it says :"256K bytes off-chip SRAM memory" (whch translates to 128 X16). That is 0x1ffff in length, which fits the Zone6+Zone7 scenario.

Where do I get it wrong, Tommy? Do I calculate memory lengths wrongly?

Thanks,

Panagis

Dear Tommy,

I am probably wasting your time, again, but I want to recap and make sure that I have understood it properly:

1) I can set in my linker file 

ZONE7P:      origin=0x200000, length=0x1ffff

2) This will allocate the full size of available external memory of my eZdsp F28355 to one memory block, sized 128Kx16=256Kbytes.

3) In my InitExtMemIf.asm file I have to make sure that I set the appropriate GPIO-mux register values, so that chip-select pins for Zone7 are used for that purpose and not for digital input/output (i.e., XZCS7n).

4) If all the above are done correctly, I can assign in my linker file my .ebss to ZONE7P, which can be 256K bytes of code long (if I do not add some other on-chip memory space to it).

5) There is no other external memory chip on the eZdsp F28335, no Zone6, no Zone 0.

I really appreciate your time,

Panagis 

Panagis,

I'm glad that it is working for you now.

-Tommy