Ti Resource Explorer, AM3359, Generic Example, Hello Example, configured as Cortex M3

Dave Page said:

Start from installer, TI Resource Explorer, AM3359, Generic Example, Hello Example,

Do you mean SYS/BIOS examples?

If so under SYS/BIOS -> ARM -> AM33x Cortex A8 there are two sub-sets of AM3359 examples in CCS 5.5.0.00077:

 

The first AM3359 set, under TI target examples -> Generic examples are for the A8 core of the AM3359.

The second AM3359 set, under Generic examples are for the Cortex M3 core of the AM3359.

I think the confusion would be avoided if the SYS/BIOS -> ARM ->  AM33x Cortex folders in the TI Resource Explorer were labled as which are for the Cortex A8 .vs. Cortex M3 cores.

Thanks for the reply.

In my case, I was looking for AM3359, skimmed to the end of the list, and selected it, assuming "AM3359" and "AM3359" were the same.

I was under the (mistaken?) impression that the M3 on the AM335x ran masked-ROM firmware and is for all practical purposes not available for end-user programming. If so, M3 examples should perhaps not exist in the Example Projects -- this would be an advanced user/TI internal process. Does SYS/BIOS run on the AM3359's M3?

Dave Page said:

I was under the (mistaken?) impression that the M3 on the AM335x ran masked-ROM firmware and is for all practical purposes not available for end-user programming.

The M3 runs code from SRAM. The A8 can load the M3 program into SRAM and then release the M3 from reset (see the AM335x TRM for details). See the Linux / StarterWare AM335x software for some examples of this.

I did at one point create and download a non-SYS/BIOS program for the M3 using CCS - but you have to arrange for the M3 to be released from reset before the M3 program can be downloaded by CCS. See http://e2e.ti.com/support/arm/sitara_arm/f/791/p/284652/994076.aspx

Dave Page said:

Does SYS/BIOS run on the AM3359's M3?

I had a quick go, but couldn't get the AM3359 M3 SYS/BIOS hello world program to compile. The RTSC platform was set to "ti.platforms.stellaris:AM3359" but the compile failed with the error:

making package.mak (because of package.bld) ...
configuring hello.xem3 from package/cfg/hello_pem3.cfg ...
The AM3359 device is not currently supported.

Thanks for the reply.

SPRUH73J 8.1.4.6 is the relevant TRM reference?

So, when running Industrial SDK on SYS/BIOS the M3 has no firmware loaded and merely stays in reset.

"A firmware binary is provided by Texas Instruments that includes all of the necessary functions to achieve low power modes."

I see in sdk\starterware\examples\evmAM335x\demo there is the M3 binary (cm3image.h) and demoPwrManagement.c

---

As you suggested, I agree I would be less confused if the AM335x example project folders called M3 explicitly.

---

Also, for some reason, someone got the idea that large blocks of static initialized data should go in a header file. Since this data must only be instantiated once, and header files are made to be included from multiple compilation units, generally, it would make sense to put the binary in a .c file and provide a small header file with an extern declaration.

In this case, rename cm3image.h to cm3image.c and provide a cm3image.h with:

extern unsigned char const cm3image[];

cm3image.c would then be added to the makefile or equivalent. For simplicity, I have omitted various trivial details like guards and so forth.

Thus, cm3image.h can be included/referenced from more than one compilation unit as is customary with header files, and the compiler/linker will have one instance of the data.

An additional benefit is the working source build time is reduced, as the binary data to compiled to .o only when it is changed.

Dave Page said:

As you suggested, I agree I would be less confused if the AM335x example project folders called M3 explicitly.

This has been done in CCSv6 beta 3: