SPI Programming in P2ASM
in Propeller 2
Hello!
I been working with SPI code a bit and the onboard SPI flash for the P2 Edge. I stumbled upon this code for an SPI programming but ran it through FlexProp and got an error for this line:
https://forums.parallax.com/discussion/165060/spi-flash-programmer-code/p1
testin #spi_do wc
to this
testp #spi_do wc
However, it doesn't seem to blink anything. I was able to try some of the code for reading and changed a few things. When I Compile and Flash a program via FlexProp the program is stored. I can then read/run the program on flash. Not sure why the code in the thread does not seem to work for the writing though.
Comments
testp looks right. Not sure why doesn't work... Maybe post full code?
You can get the spreadsheet with all the P2 assembly instructions here:
https://www.parallax.com/propeller-2/documentation/
Hey there @Rayman!
Sure thing! Here is that complete code:
I only changed that line in FlexProp. But even then it doesn't work as it should i think. I know it's writing something though since it overwrote the program i had in place previously on the spi Flash. I've been having a bit of trouble with this thing having the boot mode on/off. Very weird behavior at times. I got the read working from using the manual a bit and this code.
Yes, testp is the correct instruction. This code is for PNut (FlexProp does inline assembly differently), but this code does work.
Hello @JonnyMac!
Thank you. Okay I did get reading working in another program. I think i'll pick apart the writing part a bit under FlexProp and see what I come up with.
I recommend use of SPI clock mode 3 rather than 0. The shared SD card wiring conflicts much less when the clock idles high.
Howdy @evanh
I'll give this a shot as well in the future. Would this wiring conflict cause an SD card to randomly delete itself? I went through some SD card code and created a driver for writing which works based on the reading you had helped with before. I noticed if I ran the code a few times though it blew away the SD card once i tried to read. Off-topic but just curious.
All it would take is the erasure of block zero to stop a SD card from mounting correctly. So, yes, routines built to write blocks can easily accidentally make the card look empty. There is no filesystem management by the card itself.
As for SPI clock mode 0, I expect it would more likely cause lock-ups rather than erasures. But I have no specific evidence of what actually happens though.
Another problem I discovered recently is the historical FSRW SD card FAT filesystem for the Propellers has had deficiencies in its driver layer that did not wait for card busy condition. This is particularly bad thing when writing blocks. The chances of skipped blocks is high.
If you've been using FSRW software then that would explain filesystem corruption.
Well, the CRC checksums are supposed to protect against such corruption, but SPI mode doesn't use them by default... On the P2 nothing should be stopping us from using CMD59 to enable them.
Thanks for this. That narrows things down a bit. I'm doing FAT32 cause that's what I'm most familiar with.
I got a little further but I'm pretty sure the program never moves from hub ram to the flash.
I may plug away at understanding it a bit more later. Also, I think i might need to generate a new signature. I noticed i was using the one found in the example found here: https://forums.parallax.com/discussion/165060/spi-flash-programmer-code/p1. Though honestly it does work if run from hub ram. I kept in the testp but also replaced the testb with cmp
There's some sample flash programming code in spin2cpp; for example, in Chip's parallax file system (include/filesys/parallax/flash_fs.spin2) and in the littlefs file system code (include/filesys/littlefs/SpiFlash.spin2).
If you're trying to learn how to write programs into the flash, the sources for loadp2 or propeller-loader would be useful. On the P2 booting from flash is a two step process: the ROM loads the first 256 bytes (or so, I may be misremembering the size) from flash into RAM, and then runs that. So the first part of the flash must be a small stand-alone program capable of loading the rest of the program into flash. Chip's code for this is the file "flash_stub.spin2" in the loadp2 source code (https://github.com/totalspectrum/loadp2).
Hiya @ersmith!
Firstly, thank you for all your efforts on FlexProp.
Yes, exactly. I’ll have a look at this stuff before I continue. I would like to finish this before moving onto dual I/O.
+1 to this. Mode 3 or problems with SD cards