sw_flashlib_examples

[phalt]

A new and interesting project has been added to the XCore Github:

https://github.com/xcore/sw_flashlib_examples

Giving examples of how to write and read to FLASH on boards.

Seems like a really interesting base for a few projects or applications?

[Skeksis]

That's handy, I'd just come on to the site to have a look for something like that!

Thanks for the find phalt :P

[phalt]

As far as I'm aware flash can only be grabbed from core 0 (just had a chat with some other XMOS dudes) but if it's what you spoke to me about earlier you might be able to do what you want to with it easier than the SRAM

[lilltroll]

Can this be extended for block-based devices like micro SD cards ?

There were some discussions about this a long time ago, and for an example larry wrote this
bootloader.

https://www.xcore.com/projects/xs1-l2-custom-loader

It is not for any application, but sometimes it would be nice to use a boot-loader in the OTP, which continues reading on a SD card. SD card give you very large amount of memory for little money.

Correct me if I'm wrong, but even with a bootloader the pin-select would make it possible to still choose serial flash as boot source instead, as long the security bit is not set in the OTP !?

The XDK has had this option from the "start", even with a GUI, choosing a file to run from the SD card.
But the bootloader was only given as an bin file to the public back then.
Maybe time to update the source and put it on github ?

It is way to update the firmware in an embedded system without USB or Ethernet connection. The end customer can put the SD card in his och hers laptop and download the latest code to the card, without having an XTAG or knowing anything about that or embedded system.
Copy a file to a SD card, is something that every computer-user understands.

[MaxFlashrom]

Can this be extended for block-based devices like micro SD cards ?

Correct me if I'm wrong, but even with a bootloader the pin-select would make it possible to still choose serial flash as boot source instead, as long the security bit is not set in the OTP !?

The data sheet(I'm reading XS1-L01A-TQ128 Datasheet section 5.8) shows that bit 5 of the security register determines whether to boot from OTP if it is set. If it is set the mode pins[3:2] are ignored and boot is always from OTP. It may be possible to read the mode pins in your OTP program and revert to the old behaviour, by jumping back into the original boot ROM? (or is this hidden by being maskedby OTP if enabled?) In any case, if your program can read these pins you can then modify the behaviour. I seem to remember segher saying something about reading their state programmatically?

This would be a useful option, although it does perhaps expose a potential security hole in some applications, which is likely why it works in the way it does currently.

Max.

[lilltroll]

I was mostly thinking of a hardware switch on a preproduction card. To change bewteen serial flash or OTP->block flash. But in the production version there would not be any serial flash to reduce the BOM, only in the inhouse version the serial flash would exist to be more easy to debugg.
They can share the same PCB, but you do not need to populate the serial-flash in the production version.

Another card from another vendor has it this way, and I found it to be nice.
You can play with your code and degug as usual, or you can change the DIP to read the SD card instead holding a stripped bin file.

The XMOS toolchain already has the stripping option, so that isn't any problem.