- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hi Team,
Good day, we have received query from customer regarding TMS320F28335. For me to not miss any information, ill copy the query below.
"
Here: e2e.ti.com/.../419126
In this post it says..
"I am initializing the external memory in DSP2833x_CodeStartBranch.asm using InitExtMemIf
I have got InitExtMemIf. asm (David M. Alter) file from the previous post in TI community and have modified it.
I have done modifications in the InitExtMemIf. asm file based on the value of GPCMUX1, GPCMUX2, GPBMUX1, GPAMUX2 and XTIMING6 given in the gel file."
However, the program doesn't run properly.
All my program is doing is switching on the LED onboard the eZdsp.
I need to activate the external memory, because my actual .ebss fits only on the external memory (256kb)
(the .ebss of my actual FFT programme)
The code doesn't look like it is runnning, as the on board link does not switch on. I have also uncommented “XINTF_Enable” in the .gel file. "
Please see attached files."
Thank you and looking forward for your kind response.
Regards,
Maynard
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:
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,
I sympathize with your request for comprehensive programming support from Simulink down to silicon. I am unfortunately not familiar with the Simulink environment and its underlying code-generation and build procedures because it is a third-party tool that is not supported by TI. My understanding is that there are varying degrees of joint development between Mathworks and hardware manufacturers. In the case of C2000 devices, the development is done solely by Mathworks. As such, my expertise is limited to the C2000 devices and usage via CCS.
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:
Next, if you look at your DSP2833x_CodeStartBranch.asm file, you can see that the custom start section is aliased to codestart, whereas the standard C-initialization section is aliased to _c_int00:
Your .MAP is pointing to _c_int00 in RAM as the entrypoint, which means that the program is bypassing DSP2833x_CodeStartBranch.asm:
I assume that the initialization is not working when performing an emulator Load-Run because the defined .ebss space is unreachable without XINTF initialization. And for Flash-Boot from power-on, I see nothing mapped to the Jump-to-Flash branch address at 0x33FFF6:
For reference, this is what the run-from-flash example in C2000Ware produces in its .MAP file:
And:
In CCS, there is a project linker option to specify a custom entry point:
I do not know how this is done with Simulink. I expect that Mathworks would be able to provide guidance.
-Tommy
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
Panagis Vovos said: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
Ok, I see that now.
Panagis Vovos said: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 */
The GEL file is only referring to the theoretical capabilities of the F2833x device. The real-world usage depends on how the device is configured and what components are connected to the device. I was working under the assumption that you have a memory correctly interfaced with F2833x using the Zone 6 CS.
Panagis Vovos said: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.
The Spectrum Digital (third party) EzDSP board has a memory installed on Zone 7:
Panagis Vovos said: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.
The name of the section is arbitrary for human readability, however the address range determines which Zone the XINTF uses for external memory access:
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
