SYSBIOS 6.32.5.54 and TMS320F28335; BIOS_start()

Frank,

Boot is a utility module intended to provide a basic bootstrap mechanism for the application.  Some people use it, some don’t.  It does not setup FLASH wait states, but there have been some discussions about adding this in the future.  I’ve not heard of any talk of enabling the prefetch mechanism.   

I think a typical use case is to use Boot to quickly get to main(), and then do further device configuration and optimizations at that point, for example, using controlSUITE routines.  These same routines can be used at different points of runtime too, as CPU frequencies are changed for different application modes.

So, no, you aren’t missing it.  Boot facilitates boot from FLASH by the device boot loader, but it doesn’t do any configuration of the FLASH controller.

Scott

Scott,

thanks for your explanation how the SYSBIOS boot currently works - which is somehow not what it should (or could) be. With this default boot start and no other additiona setups, SYSBIOS runs the FLASH only at 9.3MHz (150MHz/16)!

Next issue: When I, as you suggested, postpone my FLASH - setup into the beginning of main, then I get a clash of the SYSBIOS linker command file TMS320F28335.cmd (part of the SYSBIOS minimal setup) and the controlsuite based linker command file (F28335.cmd). Why does the SYSBIOS - linker command file NOT define the section "ramfuncs"? This section is required to speed up the FLASH by calling function InitFlash(), also defines in "InitSysCtrl.c" of controlsuite. So I am either forced  to remove the Sysbios linker command file and to replace it by the controlsuite file, or to write my own additional linker command file just to define the ramfuncs section. This is cumbersome and disrupts the logical structure of the project.

Also I do not agree with you, that customers will change the CPU frequencies at different points during runtime. All customer projects, which I know of, will set the FLASH speed at the beginning of the code to maximum. I've never seen a project, where the FLASH speed is again reduced during runtime. In most cases C2000 is not targeted for battery powered systems, where FLASH power consumtion could be a problem. 

So please consider to add a call of controlsuite "InitFlash()"  to the SYSBIOS boot sequence. I would prefer to have this function additional to the "bootFromFlash" switch, eventually with a few more lines to specify the FLASH and OTP waitstates and an enable switch for the FLASH code prefetch pipeline.

Thank you.

Frank,

Thanks for your inputs on this.  

I filed an enhancement request to add FLASH configuration to the Boot module: Bug 374708 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=374708)

As far as incompatibility with the controlSUITE linker command file… can you confirm that you are using ti.platforms.tms320x28 to build the application?  And what version of XDCTools?  The TMS320F28335.cmd file I see indeed places the ramfuncs section.  If you can confirm your setup and versions and the exact problem, I can ask others who are more familiar with this...

Thanks,
Scott

Scott,

regarding the linker command files: In my test-project  I used XDCTools 3.22.4.46  and the platform is: ti.platforms.tms320x28: TMS320F28335. The linker command file, which is added automatically to my project (TMS320F28335.cmd) does not define a section "ramfuncs" - in contrast to the controlsuite based linker command file.

Any news after a year?

The recent version of C2000 - BIOS (6.34.2.18) still does not initialize the C2000 Flash properly! No call of InitFlash(), the FLASH waitstate - registers still running with 15 waitstates! 

Why was the bugreport from March 2012 not solved?

Frank,

Unfortunately, this is still an open enhancement request. We have not forgotten about it, but it never made the cut for a release. We are hoping to address it in a future release soon, but do not have a time frame yet.

Todd