Code doesn't start on reset / power-cycle.

To add, the compiled code will install and work correctly when installed via uniflash.  Is it writing to ram when I load?  Is there a switch in the config to get it back to writing to flash?

Not sure if I understand the latest comment:

- Do you mean that if you use CCS and CCS flash the target it doesn't work when you reset but if you take the .out file CCS generate and flash the target with this the target runs after a reset? 

---

- Do you see any difference if you use rfCarrierWave or the empty example? The latter one uses the 32 kHz oscillator. A typical issue with similar symptoms as you have is that the 32 kHz does not work/ is not selected. The former example doesn't go into standby and hence the 32 kHz is not an issue.  Hence this test will tell if it's a problem related to this. 

Both CCS and Uniflah does the same thing, it store the resulting file in flash. 

First bit is right -- CCS doesn't seem to be flashing the target, but the .out file works in uniflash.

I'll try the rfcarrierwave and empty examples (I've not tested on those yet).  Thanks.

Have you tried to read back the flash content using Uniflash when you flash the device with CCS and compare it with when you read back after flash with Uniflash? The resulting hex file should be equal but for some reason it seams not to be the case? 

I'll try that first.  I've got some stupid meetings to get out of the way first.

Right.  I had a think about a few aspects of this over the weekend and have just tried them out.  It seems to be a BIM thing -- I was clearly using the factory BIM, had wiped it out using NVS writes and have restored functionality by rewriting the BIM.  This leads to new questions that I can't find answers to -- does anyone know of a good tech note about what BIM is actually doing re. the boot sequence and CCS?

What are the sequences (CCS switches) for booting -- as far as I can tell, there's:

• 'enable bootloader' in syscfg -- this seems to instruct the bootstrap (not BIM) to look in off-chip flash for code and is thus a red-herring.
• OAD_IMG_x=y (linker preprocessor) seems to instruct the build/flasher to put the code in the onchip or offchip flash.  x can be A, B or E, indicating onchip slot 1, offchip slot 2 or external flash.  But what does the 'y' signify?
• More on OAD_IMG -- I think that if I don't have one of these then I don't use BIM -- is this the case? 
• FLASH_ROM_BUILD (compiler predefined symbols) is all about whether to use the ROM BLE where possible, or just create all BLE functions in the compiled code -- thus is a red-herring.  However, there's also a FLASH_ROM_BUILD=x in the linker preprocessor -- what does the 'x' do?
• FLASH (linker preprocessor) doesn't appear to be documented.
• It isn't clear what SECRET (linker preprocessor) does -- does it mangle the code in some way?  Is it a BIM thing, a bootstrap thing or a flash-protection (read deny) thing?
• Are there other important switches for the use of BIM?

The main question is -- I don't need the BIM as I don't need OAS -- can I have the rom boostrap point simply to code in on-chip flash when using TIRTOS?  The docs imply (but don't state) that I can't do this, but I don't understand why.  I can't stick with BIM and on-chip as my code exceeds the 60K limit for on-chip.

Also -- a weird thing.  I accidentally used BIM (off chip) when testing using code compiled with OAS_IMG_A=1 -- but it still worked.  Have I misunderstood OAS_IMG_A or does BIM (off chip) also look on-chip if it can't find anything in off-chip flash?

Thanks.

Before going into the details with your questions:

From what you write I get the understanding that you for some reason use BIM but are not planning to use OAD.

- Could you cover some on why you are using BIM if not needed?

- Could you cover what sort of project you are trying to implement? 

I want to understand a bit on a high level what you need and are trying to do before going into details 

It is a simple bluetooth data transmitter.  It uses the usual rtos functions (clock based intermittent BLE data send if connected).

We didn't use bim on purpose -- I was under the impression (mistakenly) that the bim was in the bootstrap, and was unavoidable.

We also based the probject on prjzero; this has worked out well, other than the point about all the compiler switches being to use bim -- really I just want to know which switches to change to move from bim to code run from the bootstrap.

We'd prefer not to use bim as it doesn't add anything.

Thanks for your time on this.

Okay.  All resolved.  It wasn't too tough to make Prjzero non-OAD/BIM.

The code was simple enough -- just remove references to OAD functions.  Note that there's a switch in main.c that mucks things up 'USEOAD' -- the only way I found to resolve this was to comment out the #ifdef USEOAD (and the endif).

Beyond the code, the main problem was getting the memory map to work -- the simple peripheral memory map in the .cfg works well enough.  I'd note a problem (that threw me for a few hours) was that CCS doesn't actually look for a named .cfg but just picks the first .cfg it finds, traversing directories if necessary.  The only solution is to only have one .cfg and don't do as I did and think that renaming the .cfg will work.

It would be easy enough for TI to produce a document stating the steps needed to move projzero to non-OAD -- you make it sound much harder than it is.

Cheers.

Hi,

Thank you for posting the solution!

Cheers,

Marie H