I'm currently tuning some code written for an STM32F070, where we use one byte on user option byte to keep some flags between Resets, using:
FLASH_ProgramOptionByteData(ADRESSE_OPTION_BYTE_DATA0, status_to_store);
Reading carefully the datasheet from our new STM32F446 lets me think that it is no longer possible to use option bytes to store one user byte...
1 - Am I Right with this assertion ? If not, what did I miss ?
2 - Is there some workaround, not involving to rewrite a sector of the flash ?
I am not an expert on stm32, rather still a beginner, but maybe you could have a look on the RTC backup register to hold your data ?
Related
I don't make sure, but I think the ScadaLTS no have the modbus 16 function. I need write in 9 registers simultaneously, but the data type that ScadaLTS give does not satisfy my need. I did try to use the type data "fixed length string" but I can't represent the code 0 in ASCII, if I could, it would work.
Finally, I hope to find help and thank you very much in advance.
Modbus function 16 is writing multiple holding register address at once, we cannot write it one by one, and must use fc 16 code. But there is no option to write to multiple address at modbus datapoint. I need this feature also,
I'm using Intel's Pin Tool to do some binary instrumentation, and was wondering if there an API to get the instruction byte code at a given address.
Something like:
instruction = getInstructionatAddr(addr);
where addr is the desired address.
I know the function Instruction (used in many of the simple/manual examples) given by Pin gets the instruction, but I need to know the instructions at other addresses. I perused the web with no avail. Any help would be appreciated!
CHEERS
wondering if there an API to get the instruction byte code at a given
address
Yes, it's possible but in a somewhat contrived way: with PIN you are usually interested in what is executed (or manipulated through the executed instructions), so everything outside the code / data flow is not of any interest for PIN.
PIN is using (and thus ships with) Intel XED which is an instruction encoder / decoder.
In your PIN installation you should have and \extra folder with two sub-directories: xed-ia32 and xed-intel64 (choose the one that suits your architecture). The main include file for XED is xed-interface.h located in the \include folder of the aforementioned directories.
In your Pintool, given any address in the virtual space of your pintooled program, use the PIN_SafeCopy function to read the program memory (and thus bytes at the given address). The advantage of PIN_SafeCopy is that it fails graciously even if it can't read the memory, and can read "shadowed" parts of the memory.
Use XED to decode the instruction bytes for you.
For an example of how to decode an instruction with XED, see the first example program.
As the small example uses an hardcoded buffer (namely itext in the example program), replace this hardcoded buffer with the destination buffer you used in PIN_SafeCopy.
Obviously, you should make sure that the memory you are reading really contains code.
AFAIK, it is not possible to get an INS type (the usual type describing an instruction in PIN) from an arbitrary address as only addresses in the code flow will "generate" an INS type.
As a side note:
I know the function Instruction (used in many of the simple/manual
examples) given by Pin gets the instruction
The Instruction routine used in many PIN example is called an "Instrumentation routine": its name is not relevant in itself.
Pin_SafeCopy may help you. This API could copy memory content from the address space of target process to one specified buffer.
I have an ATXMEGAA3BU processor and I use a CrossPack on my MacOS. I would like to use my old USBASP pragrammer which is "configured" to programm the CPU through the PDI interface - that is not a problem.
The problem is that I do not know how to setup the FUSES on this ATXmega.
For ordinary CPU like ATMega8 the sequence in the Make file was simple.Just use this: FUSES = -U hfuse:w:0xd9:m -U lfuse:w:0x24:m
But the Xmega has five FUSEBYTES and I have a problem with them... so the simple question is "how to change e.g. JTAGEN from 0 to 1"? It is located in teh FUSEBYTE4 as bit 0. How to tell the CrossPack (avr-dude) to change this or other from e.g. FUSEBYTE0?
Thank you...
Maybe this is related to Robotics StackExchange.
But I will try to answer here.
If it's possible for you to switch to windows, The fuse bit changing progress is very easily done with CodevisionAVR. With just some single clicks it's done. and it doesn't have the headaches of this terminal commands.
Please refer to the datasheet for xmega a3bu at : http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf
The name of the fuse bytes are: FUSEBYTE0, FUSEBYTE1, ... FUSEBYTE5. There's no FUSEBYTE3. Have you tried
-U fusebyte0:w:0xd9:m -U fusebyte1:w:0x24:m -U fusebyte2:w:0x24:m and so on. You could give it a shot with exercise precaution while calculating the fuse bits and the lock bits.
I know this is probably too late for OP, but for others (like me) who come across this question, you can also add
FUSES =
{
0x00,//sets jtag address
0xAA,//fuse byte 1
0x9D,//f byte 2
0x00,//unused
0xDE,//f byte 4
0x1E //f byte 5
};
to the top of your main.c file and the compiler / programmer will take care of flashing them.
Tested on xmegaA4.
I have a question regarding the persistence (storage) of data values in a PIC24F, even after the PIC has been turned off.
I have read through the datasheet(s), but am confused regarding the difference of the EEPROM and Flash memory.
For example, say I have a variable "x", is there a way for the value of "x" to persist even after the PIC has been shut off? I know programs can persist in the flash memory so long as the code is compiled in Stand Alone Operation (COE_OFF). However, I am specifically wondering about data values.
If I make the program memory and the memory for the data value non-volatile, will it persist even when the power is off?
Do I need to declare the value as "static", example: static int x; ?
Or am I wrong and there isn't any way for a data value to persist even after the power has been turned off?
Thanks for the help and clarifications!
You must write to flash in pages, using the TBLWTL and TBLWTH instructions, as you have read in the datasheet for your device. This is typically for updating your software through a bootloader, and it does not sound like this is what you are after.
To access the EEPROM you can do it in smaller units, and there are compiler convenience macros for declaring where in the memory map a variable should live. You can specify that the variable lives in EEPROM and the compiler will generate instructions for accessing and updating that for you. You can also use the compiler intrinsics or the TBL instructions for reading it directly.
The declaration will probably look something like:
unsigned __attribute__((space(eedata), aligned(2)) my_eeprom_variable;
Look at the generated assembler to see what the compiler does when you access the variable.
Declaring a variable static only has traditional C semantics; it controls the scope of the variable and the initialisation rules.
Contents of registers and RAM variables are lost when power is turned off. Flash and EEPROM are both persistent. Flash can only be erased in large blocks - 128K and up depending on the type that you have. EEPROM words can be individually read or written. If you have EEPROM, that's your best bet for saving a small amount of data. Usually you have to read and write EEPROM serially.
thanks for the responses!
After some other suggestions I read through the MPLAB C30 Compiler datasheet again, and found the "persistent" attribute.
Per the datasheet:
"The persistent attribute specifies that the variable should not be initialized or cleared at startup. A variable with the persistent attribute could be used to store state information that will remain valid after a device reset."
I'm going to try using this to see if it will work.
Well, the question says it all.
What I would like to do is that, every time I power up the micro-controller, it should take some data from the saved data and use it. It should not use any external flash chip.
If possible, please give some code-snippet so that I can use them in AVR studio 4. for example if I save 8 uint16_t data it should load those data into an array of uint16_t.
You have to burn the data to the program memory of the chip if you don't need to update them programmatically, or if you want read-write support, you should use the built-in EPROM.
Pgmem example:
#include <avr/pgmspace.h>
PROGMEM uint16_t data[] = { 0, 1, 2, 3 };
int main()
{
uint16_t x = pgm_read_word_near(data + 1); // access 2nd element
}
You need to get the datasheet for the part you are using. Microcontrollers like these typically contain at least a flash and sometimes multiple banks of flash to allow for different bootloaders while making it easy to erase one whole flash without affecting another. Likewise some have eeprom. This is all internal, not external. Esp since you say you need to save programatically this should work (remember how easy it is to wear out a flash do dont save unless you need to). Either eeprom or flash will meet the requirement of having that information there when you power up, non-volatile. As well as being able to save it programmatically. Googling will find a number of examples on how to do this, in addition to the datasheet you apparently have not read, as well as the app notes that also contain this information (that you should have read). If you are looking for some sort of one time programmable fuse blowing thing, there may be OTP versions of the avr, and you will have to read the datasheets, programmers references and app notes on how to program that memory, and should tell you if OTP parts can be written programmatically or if they are treated differently.
The reading of the data is in the memory map in the datasheet, write code to read those adresses. Writing is described in the datasheet (programmers reference manual, users guide, whatever atmel calls it) as well and there are many examples on the net.