Real memory size of SPI chip?

[Skydev0h]

It seems that the memory size of SPI chip is far beyond 32K.

From my testing by getting manufacturer and chip id info it returned 1F 24 00 00 which corresponds to 4-Mbit chip (thats 512 KBytes!)

And from my testing (write-read-check zero address) it actually has 512 KBytes!

I have got my board from lab401, and it seems to be the common RevE-rebooted board:

Unfortunately I do not have other RevE-rebooted boards to test whether chip memory density is consistent across boards, however i discovered that there are no DataFlash chips with memory density lower than 128 KBytes.

Perhaps 32K of memory that manufacturer declared actually is about the atxmega program memory itself? May need some testing with other physical RevE-rebooted boards.

[iceman1001]

aha.. very interesting, the 32kb idea fits with atxmega mpu ... and a onboard extra 512kb flashmem could be possible then. If we have that extra mem, we can do some more fun things :)

[iceman1001]

should have that test in a neat package in order for ppl to be able to report back here their results aswell

[bogiton]

Have you guys identified the SPI chip model? It seems that the inscription on it is missing.

[Skydev0h]

@iceman1001
Making that test user-friendly and neatly packaged requires exposing FlashRead and FlashWrite
(optional) functions with uint32_t arguments, creating new terminal command for testing, maybe iterating each N pages for faster execution. To make it faster and do less strain on the flash storage it can be written in a way that it backups zero page on flash, fills it with some random data, and then tries to read all pages to find memory wraparound, restoring the page afterwards.

It may be much easier to expose 0x9F read information from flash function, i have implemented it like this:

void FlashReadInformation(void* Buffer) {
	while(FlashIsBusy());

	MEMORY_FLASH_PORT.OUTCLR = MEMORY_FLASH_CS;
	SPITransferByte(0x9F);
	SPIReadBlock(Buffer, 4);
	MEMORY_FLASH_PORT.OUTSET = MEMORY_FLASH_CS;
}

Right now from results of my tests i do not have reasons to do not trust output of this function.

@bogiton
Looks like AT45DB041D from Density Code : 00100 = 4-Mbit and manufacturer code 1F

[kevin2008-01]

[iceman1001]

Exposing the get manufacture/device id function will do just fine. PR?

[iceman1001]

If this correct, the 8 slots can now have much larger memory allocations :) No need for that annoying 4k/1k solution. We can also have seperate memory for switching between type of cards.

Like also saving signature / configs, counters etc for UL/ntag styled.

[bogiton]

@Skydev0h I believe that you are right. If anyone is interested this is most likely the SPI chip's orientation and pinout:

[Skydev0h]

Added PR, it would be nice to get some info from people here.

[iceman1001]

suggested some change

[Skydev0h]

What, where, dont see anything...

[iceman1001]

look at your PR

[Skydev0h]

Really, i dont see anything there



No comments, no change requests, no commits from maintainers. wtf?

[iceman1001]

Strange, refresh your browser cache? ctrl-f5?

[Skydev0h]

Used another browser with the same result - nothing.
(I dont think github would use cache headers that incorrectly)
Maybe you unintentionally limited visibility of the comment?

[iceman1001]

well, it could be related to the GDPR law going on... Let me check my settings.

[iceman1001]

The settings looks normal. I never ran into this problem on GitHub before. that you can't see comments to your PR...

[ceres-c]

Same as @Skydev0h for me, I can't see your comment @iceman

[iceman1001]

@bogiton let me test an idea since you are a collaborater, can you see the review ?

[iceman1001]

plottwist, Olaf the manufacturer, said it was a 1Mbyte flashmem now that I asked. Which is a bit more than @Skydev0h 's findings. Now I'm excited, we don't have any space limits anymore. We can start adding a better memory layout for a slot. And the logging will also work!

[iceman1001]

btw, I just merge the PR instead. I only wanted to have a better option for when printing the manufacture/device id is not found.

[Skydev0h]

@iceman1001 too bad i could not see the comment, but you could commit that yourself - i did not deny commits from collaborators. Anyway i do not expect that situation to ever happen - that our boards have some non-existing chip outside of dataflash specifications.

Well, i have 512 KBytes flash mem, afterwards it wraps around, so it may not be safe to expect having 1 MByte memory for everyone, now when the PR is merged we can ask ppl to test their own SPI chips with this commands and post results, they may be valuable determining the real minimum amount of memory in end-user devices.

Too bad that we cannot use SPI for storing code because of AVR's Harvard architecture, but we can use flash to store data (of course in case of realtime data like logging of RF commands it should be first cached to RAM, because writing to SPI is VERY slow - for example i had to add caching to entire MFUL data because my reader did common write-read-verify pattern, and it could not do that in time without RAM caching!)

Anyway as for the current code, 32K may actually be a problem - more strange is that near the 29K-30K it clashes with bootloader, although there is dedicated memory space for bootloader... which is strange.

[iceman1001]

Dunno why it couldn't be seen. Anyway, I merged it and we can go on with this piece of information.
Apparently there are different hardware revisions of RevE rebooted with different flashmemory sizes.
So yours is 512kb, I am curious on how many different ones there are.

We can also add to the GUI an option to share their findings with the press of a button :) in order to collect it faster. I don't think there is too many people who are actually using this fork. :/

I guess we would need to figure out a buffer memory for the active slot that gets save to flash memory at intervalls? or after a timeout of no use.

There is so much little info for being a opensource from the beginning. There should be lots of info from offical revE.

I belive the whole memory mapping part in current software is the most confusing part. I really don't understand the mix between a buffer array in ram or when its read from flashmemory...

[iceman1001]

@maxieds Now this piece of information enables logging without problem. :)

[bogiton]

A bit late to the party, but I just tried out that flashinfo command:

--> SPI_FLASHINFOMY
101:OK WITH TEXT
Manufacturer ID: 1fh
Family code: 1
Density code: 5
MLC Code: 0
Product version: 0
Flash memory size: 8-Mbit (1024-KByte)

1MB flash mem! That's pretty amazing!
So, essentially, that means that when we use the FlashWrite/FlashRead functions (from Memory.c), we can access the whole space? (Didn't check if you committed any changes there).
Logging is now definitely possible. But, I think we should probably figure out when to write to the flash.
Have you measured how slow are the writes to the spi flash mem?

[iceman1001]

Also late to the party,

--> SPI_FLASHINFOMY
101:OK WITH TEXT
Manufacturer ID: 1fh
Family code: 1
Density code: 5
MLC Code: 0
Product version: 0
Flash memory size: 8-Mbit (1024-KByte)

[slurdge]

Mine:

--> SPI_FLASHINFOMY
101:OK WITH TEXT
Manufacturer ID: 1fh
Family code: 1
Density code: 4
MLC Code: 0
Product version: 0
Flash memory size: 4-Mbit (512-KByte)

[killadm]

--> SPI_FLASHINFOMY
101:OK WITH TEXT
Manufacturer ID: 1fh
Family code: 1
Density code: 5
MLC Code: 0
Product version: 0
Flash memory size: 8-Mbit (1024-KByte)

[albockit]

me too (cheapest board from Alie****s):

SPI_FLASHINFO
101:OK WITH TEXT
Manufacturer ID: 1fh
Family code: 1
Density code: 4
MLC Code: 0
Product version: 0
Flash memory size: 4-Mbit (512-KByte)

[exander77]

@albockit Probably same as you have.

--> SPI_FLASHINFO
101:OK WITH TEXT
Manufacturer ID: 1fh
Family code: 1
Density code: 4
MLC Code: 0
Product version: 0
Flash memory size: 4-Mbit (512-KByte)

[n3o59hf]

101:OK WITH TEXT
Manufacturer ID: 1fh
Family code: 1
Density code: 5
MLC Code: 0
Product version: 0
Flash memory size: 8-Mbit (1024-KByte)```

[securechicken]

Bought at Lab401; Q1 2019.

--> SPI_FLASHINFO
101:OK WITH TEXT
Manufacturer ID: 1fh
Family code: 1
Density code: 5
MLC Code: 0
Product version: 0
Flash memory size: 8-Mbit (1024-KByte)

[iceman1001]

Maybe we should to a wiki page where we enter all the different memory sizes we have encounted?
@ShinHub ?

[Skydev0h]

So far it seems that there is nearly same amount of 4 and 8 Mbit chips that are encountered.

[securechicken]

@iceman1001 @Skydev0h Yeah or more preferably a page to summarize all of the hardware specs for commonly found RevE Rebooted. I had to look for SRAM, EEPROM, Flash and related sizes many times. I did however already create a page for SPI Flash reference, with links to data sheets, and to a memory management library on GitHub that may be a good source of inspiration in the future.

[iceman1001]

Now that was great initative! I think its time to close this one, since all is documented in the Wiki
https://github.com/iceman1001/ChameleonMini-rebooted/wiki/Reference-SPI-Memory

Maybe we should just name it Notes on SPI..

[securechicken]

@iceman1001 @bogiton @Skydev0h @slurdge , I also put a hardware summary page here, please fill free to complete as I do not even really know what I wrote... :) https://github.com/iceman1001/ChameleonMini-rebooted/wiki/Hardware-summary