Define address of constant in flash

[aritec]

I'd like to define the address of a constant within the image. I'd like to check the version of the factory image from the running image.

Example:
factory image:
@0x00 const unsigned char version = 200; //need to be at address 0 of image

running image:
unsigned char buffer[pageSize];
fl_getFactoryImage(BootInfo);
fl_readPage(BootInfo.startAddress, buff);
factoryVersion = buff[0];


Checked all documents, but couldn't find a clue.


Thanks
Armin

[mon2]

https://www.xmos.com/download/private/A ... rc1%29.pdf

[aritec]

not exactly what I want. (I'm aware of the data section in flash)
I wanna read partly of the factory image and to get the version of the factory image. For this, when I compile the factory image the compiler needs to store the version constant on a defined address.

[mon2]

Use the SPI flash library to perform absolute reading of the attached external flash. Using standard SPI flash read command and the address of the flash location, the value will be returned. Same principle as how the xflash tool works.

[aritec]

Thats right. The only thing now missing is the compiler #pragma or anything similar to fix the constant address for version, so I know where to read the flash.

[mon2]

Assuming that you are defining the code version for your firmware, you wish to place a marker somewhere inside your flash device?

You can use the same XMOS SPI flash routines to write to a desirable location with your data marker and then use the read routine to read that value back. That is standard practice with the SPI flash routines. However, since we are talking about flash memory, you may be required to operate on sector size boundaries. This means that even if your data marker is only say 1 byte in length, you may have to read or build up a copy of the sector size -> populate the exact data that is there now and insert your data marker -> then perform the sector size write. It has been a while since we used it but the documentation should offer this detail. EEprom you can R/W a byte at a time but flash does not work this way.

The idea here is to consider to read from say the END of your flash device which will be blank / not used. Then write your code version there and read back using your flash memory routines. You can also review the SPI commands for your specific flash memory used by your product. This standard SPI command set will be applicable here and will explain how many locations you must write in a single flash memory write session.

If you wish to read the firmware version as generated by the XMOS tools then you must review the low level details about the DFU format. This documentation should be posted here somewhere but consider to do a Google search on this topic. Once these details are known, you can read back the required information using the SPI tools.

[aritec]

The last sentence hits the point: "Once these details are known, you..."

For this, I'd like to tell xmake where to place my "constant version", so I can read it out, I already made Google searches, but without success.

[infiniteimprobability]

Here's the image header info (excuse formatting but tabs are preserved so you can do text->columns in excel or something)

Field 5 (version) may be useful..

Code: Select all

Offset	Field	Description
0	Image Tag	0x1a551e5 for tools versions Tools12 and below; 0x0FF51DE for tools version Tools13 and above
1	Page CRC	CRC value for 256 bytes (64 words) from offset 3 of the Image Header Table
2	Image CRC	CRC value for the full image from offset 3 of the Image Header Table
3	Image Features (TOOLS 13)	See image features field below
4	Image Size	Size value the user requested with option --factory or --upgrade (Otherwise same as Image length)
5	Image Version	Version as specified when using option --upgrade (0 for --factory image)
6	Image Length	The actual size of the image from offset 0 of the Image Header table to then end of the Application data (or Overlay data if used)
7	Num Core Images	The number of core tables found within this image
8	Boot Image Address (TOOLS 13)	The address in RAM where the boot image address is to be stored (symbol __boot_image_address required in application)
9	Overlay Address (TOOLS 13)	The address in RAM where the overlay data is to be stored (-foverlay=flash / -foverlay=quadflash)
10	Overlay offset (TOOLS 13)	Offset in vytes from the start of the image of where the overlay data is located
11	Switch Setup Header offset (NEW TOOLS 13.2)	Offset in bytes from the start of the image of where the network setup table is located
12	Core Entry Header offset (NEW TOOLS 13.2)