After compiling, I would like to see the addresses of each global variable defined.
Is there a switch in the linker / tool chain that allows me to obtain this ?
Board is a Nano 33 BLE
Personally I have configured my IDE to output the assembler listing and hex to the sketch directory, so if I want to find out what the compiler did I can just look. This is for ATMega168/328 platforms. Nano may well be different.
This is another continuation of one of your many threads...
Retaining variables with power off
Possibility to leave variables uninitialized on boot / reset
Memory map for Nano 33 BLE
In fact it's almost identical to the memory map question.
When you start a new thread we lose all context of the previous question. The answers you get may not be appropriate, or may just be "Why?" without any context.
you can find the .elf file under AppData/Local/Temp/arduino_build_xxxx
you can use Arduino/hardware/tools/avr/bin/avr-gcc-nm to list the addresses of symbol from the .elf file
pcbbc:
This may helpPersonally I have configured my IDE to output the assembler listing and hex to the sketch directory, so if I want to find out what the compiler did I can just look. This is for ATMega168/328 platforms. Nano may well be different.
This is another continuation of one of your many threads...
Retaining variables with power off
Possibility to leave variables uninitialized on boot / reset
Memory map for Nano 33 BLEIn fact it's almost identical to the memory map question.
When you start a new thread we lose all context of the previous question. The answers you get may not be appropriate, or may just be "Why?" without any context.
You're right that all these posts are related.
However, some are not trivial, and don't get any answers (or relevant ones).
So then I try to rephrase the question, in order to get to its "core", in the hope that it makes it easier to answer...
Anyway to summarize:
Using a Nano33BLE board I want keep variables alive during a systemoff condition. This is not a power off but rather a very low power mode (about 2-3 uA) where RAM is kept on.
So far no luck. I suspect the bootloader is getting in the way, so my next course of action is to get the parts necessary for a SWD programmer, get rid of the bootloader and just upload the executable.
Alternatively, you might consider getting a FRAM.
FRAM?
A large persistant memory store like EEPROM but with a much much higher limit on writes. Adafruit (among others no doubt) carries them.
For cost reasons, i want to keep component count to a minimum
I'm not familiar with the processor or the systemoff state, but I would suspect your code is running as if it were started from a reset and re-initializing the variables. To preserve the variables, you would need to move the initialization to setup(), and then only run the initialization if the processor were reset, not if it were restarted from systemoff. How exactly you determine that I'm not sure, and the bootloader likely complicates the process.
I'm 100% sure that whatever application you have, can be done by making your own alias for setup(), performing the usual initialization inside your alias setup(), and simply calling the alias when you want to reset. In that case, you can easily control which variables are initialized and which are not.
void setup() {
bool iWantToPerformAReset = false;
mySetup();
}
void loop() {
if (iWantToPerformAReset == true) mySetup();
...
}
void mySetup() {
//initialize these variables
...
//don't initialize these variables
}
The only difference is that you will have to initialize your global variables explicitly.
I did propose this in one of the other threads. If this isn't relevant, I'd like to know why.
pjrebordao:
. . .Anyway to summarize:
Using a Nano33BLE board I want keep variables alive during a systemoff condition. This is not a power off but rather a very low power mode (about 2-3 uA) where RAM is kept on.
So far no luck. I suspect the bootloader is getting in the way, so my next course of action is to get the parts necessary for a SWD programmer, get rid of the bootloader and just upload the executable.
Are you sure that 2-3uA is a realistic goal with the Nano 33 BLE board in such a "sleep" mode ?
The low power performance of the main chip, the ARM Cortex M4 core in the nRF52840 package, is not likely to be the problem, but all those peripheral devices on the board may make this goal difficult to achieve. Here is the board schematic: https://content.arduino.cc/assets/NANO33BLE_V2.0_sch.pdf
6v6gt:
Are you sure that 2-3uA is a realistic goal with the Nano 33 BLE board in such a "sleep" mode ?
The low power performance of the main chip, the ARM Cortex M4 core in the nRF52840 package, is not likely to be the problem, but all those peripheral devices on the board may make this goal difficult to achieve. Here is the board schematic: https://content.arduino.cc/assets/NANO33BLE_V2.0_sch.pdf
2-3uA is what Nordic quotes for the processor, so I'll get more than that for sure. But even 10-14uA is ok to me.
However, that schematic is for the Nano 33 Sense in fact. The BLE has much less chips, just the IMU and one other ...
aarg:
I'm 100% sure that whatever application you have, can be done by making your own alias for setup(), performing the usual initialization inside your alias setup(), and simply calling the alias when you want to reset. In that case, you can easily control which variables are initialized and which are not.void setup() {
bool iWantToPerformAReset = false;
mySetup();
}
void loop() {
if (iWantToPerformAReset == true) mySetup();
...
}
void mySetup() {
//initialize these variables
...
//don't initialize these variables
}
The only difference is that you will have to initialize your global variables explicitly. I did propose this in one of the other threads. If this isn't relevant, I'd like to know why.
I understand the logic of your code and I'm already implementing something similar using some internal flags to find out if it's the first run or not.
However, this doesn't solve my main problem: Behind the scenes, whether you want it or not, the bootloader is probably initializing variables, thus invalidating my purpose of preserving the variables.
The bootloader is likely using ram for its own purposes and overwriting your variables, since no meaningful data is expected to be in ram at that point.
It is not the bootloader that is initializing your variables, it is the compiler that generates the code that does that. The standard demands that uninitialized global variables be initialized to 0 and the compiler obliges. So, at the beginning of execution, the initialization value is read from PROGMEM and placed in the proper ram location.
blh64:
It is not the bootloader that is initializing your variables, it is the compiler that generates the code that does that. The standard demands that uninitialized global variables be initialized to 0 and the compiler obliges. So, at the beginning of execution, the initialization value is read from PROGMEM and placed in the proper ram location.
I tried using the noinit attribute, but no success...
int __attribute__ ((section (".noinit"))) i[1000];