RAM/ROM applications

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I'm a bit confused on the distinction between the RAM and ROM applications.

* When building a RAM application with the 'download' parameter, the object code still gets programmed into ROM, right?

* Is the object code for the application loaded into RAM, and executed from RAM during runtime? Or does that just execute straight from ROM?

* Some of the documentation I was reading over mentioned that RAM applications allow for dynamic reconfiguration of the GATT database. Does that mean registering/unregistering services and characteristics, or does that only mean modifying and storing values?

* Does the build system do anything different in the build for RAM targets versus ROM targets? (Relevant: Visiting the guy that wrote the build scripts - DevOps Reactions)

0 Likes
1 Solution
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

ROM vs. RAM application assignment has caused some confusion in the past, so we eliminated this nomenclature in SDK 2.0.1.

In reality, there is very little difference between ROM and RAM applications. In both cases, object code for a user application is loaded first into the NVRAM during programming and then automatically loaded to internal RAM on boot up.

ROM applications typically have some part of the application running in the ROM, then whatever code the user writes just adds functionality to the ROM code we provide. Note here that RAM applications also use the BLE Stack in the ROM as well, hence why there is not alot of difference between the two.

Regarding dynamic configuration of the GATT DB, I am not quite sure the answer.  I know that both ROM and RAM based apps can change values. I'm also pretty sure both replace the GATT DB database on the fly. Of course the new database will need to be created within the application area for this to work.

View solution in original post

9 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

ROM vs. RAM application assignment has caused some confusion in the past, so we eliminated this nomenclature in SDK 2.0.1.

In reality, there is very little difference between ROM and RAM applications. In both cases, object code for a user application is loaded first into the NVRAM during programming and then automatically loaded to internal RAM on boot up.

ROM applications typically have some part of the application running in the ROM, then whatever code the user writes just adds functionality to the ROM code we provide. Note here that RAM applications also use the BLE Stack in the ROM as well, hence why there is not alot of difference between the two.

Regarding dynamic configuration of the GATT DB, I am not quite sure the answer.  I know that both ROM and RAM based apps can change values. I'm also pretty sure both replace the GATT DB database on the fly. Of course the new database will need to be created within the application area for this to work.

Anonymous
Not applicable

Hi, I have a question about the on-chip ROM and the EEPROM.

The code is programmed to on-chip ROM or the EEPROM?

0 Likes
Anonymous
Not applicable

The user application is programmed into EEPROM in 2073xS module.

0 Likes
Anonymous
Not applicable

Thanks. But, what's the on-chip ROM for? and could we program anything in it?

0 Likes
Anonymous
Not applicable

Bluetooth stack including some profiles uses ROM.

We can't change it since it's not Flash ROM. (It's Mask ROM.)

Anonymous
Not applicable

Totally understood. Thanks a lot.

0 Likes

Core firmware + drivers + embedded stack + profiles come preloaded in ROM (total 320 KB).

Anonymous
Not applicable

The "preloaded in ROM" mean before we got the chip from the vendor, there is no way to modify (MASK ROM). How to check the ROM FW version in the chip.

0 Likes

If you order BCM20736S or BCM20737S devices, these are pre-loaded with A1 firmware

If you order BCM20732S devices, these are pre-loaded with A0 firmware

Patches and bug fixes are applied externally through the various SDK releases and do not affect core firmware that is shipped on any of the devices.