SAMD51 and redundant XIP Flash

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

 

I want to implement a system based on ATSAMD51J19 or ATSAMD51J20 with 2 QSPI Flash and have a dual XIP application architecture (like the BIOS of a motherboard) one active and one inactive so I can have redundancy in case one for them fails at hardware or software level.

 

The following things I want to have:

  1. Launch the application from active flash module that was previous set as "boot drive",
  2. Ability to remotely (for example - over Etehrnet or UART or USB)  update the inactive flash module with new firmware while the active one is in use.

 

Based on that I have a few questions:

  1. Connecting the flash modules on the same QSPI interface with different CS lines is doable or I have to add 2 mux chips, one mux for connecting the active flash to QSPI and the second mux to connect the inactive flash to another SPI bus ?
  2. Can the specified MCU be used like this with a bootloader that can run the application from the active flash module and inside the application have the update routines implemented so I can upload a new application on the inactive flash and set a variable (bit) in non volatile area of MCU telling to boot from the inactive flash and reboot it in case it fails to launch the new firmware using the old one ?

 

Thank you for your time and best regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I’ve not used this chip or read the datasheet extensively, so my comments are general.
1. Executing from external flash can be slooooooow.
2. You can have a number of chips on the one spi bus, but they need their own cs signals
3. Usually,one would store one or more flash images in one chip and copy them to the internal flash to upgrade.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey @Kartman

 

Thank you for your input.

 

Here is my experience with what you pointed out.

1. Executing from external flash can be slooooooow.

This is true if the data blocks that are executed are greater than the ICache of MCU but for what I need is not a big issue as I already have the code running from only one QSPI Flash in XIP mode. When it comes to hardware speed the QSPI Flash modules have greater data transfer speeds than the MCU can handle (at least for the one I want to use). For more details regarding XIP performance can be found in Chapter 8 of Atmel AN 44065 "Execute in Place (XIP) with Quad SPI Interface(QSPI)".

 

2. You can have a number of chips on the one spi bus, but they need their own cs signals

I know that the SPI works with separate CS lines for each connected device on that buss but I pointed the fact of using 2 separate CS lines because one of my colleagues has came with the idea of using only one CS line and use an inverter for one of the flash chips to negate the CS line and so have only one of them active. But for what I want to do I need to be able to have them both active so I can do an update on one while the other is active.

 

3. Usually,one would store one or more flash images in one chip and copy them to the internal flash to upgrade.

I've played with this idea but if the image that gets into the internal flash is corrupted then the system gets unresponsive. Also the internal flash is limited in size and the application I want to do is bigger that that size so I need an external storage for it.

I've also played with the idea of storing the active and inactive application images on the same flash chip at specified addresses but for some reason at some point the flash chip failed (for sure my mistake in handling it not a manufacture fault) and again I got a unresponsive system.

 

I want to have this solution with dual Flash chips with MCU in XIP mode because the system will be placed in a remote area that is hard to reach, so is hard to do in field debug and fix, and it needs to have uptime as close to 24/7/365.

 

Again thank you for your input. Best regards

 

Last Edited: Mon. Sep 14, 2020 - 06:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For /CS muxing, you might be able to use the CCL peripheral in place of external logic. Configure CCL from the boot loader to select the active XIP device. The QSPI peripheral supports tweaking the /CS and SCK timing, so you should be able to compensate for CCL propagation delays.

 

You've got plenty of internal Flash for a boot loader; even one which could have Ethernet/UART/USB support built in to perform firmware updates from there.

 

Detecting corrupt firmware is easy, but how do you auto-recover from a valid-but-crashes firmware image?

 

Steve

Maverick Embedded Technologies Ltd. Home of Maven and wAVR.

Maven: WiFi ARM Cortex-M Debugger/Programmer

wAVR: WiFi AVR ISP/PDI/uPDI Programmer

https://www.maverick-embedded.co...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Steve (@scdoubleu) for the CCL hint. I will look into it and see if I can use it in this project.

 

The internal Flash is indeed more than enough to have the boot loader with the base functionality in regard of firmware updates and that is how I already have it implemented.

 

Detecting corrupt firmware is easy, but how do you auto-recover from a valid-but-crashes firmware image?

True that the detection of corrupt firmware is easy and in case of valid-but-crashes firmware I have a watchdog that monitors the MCU at preset intervals for a heart beat and trigger a reset in case MCU no longer responds. As the system has to run 24/7/365 it has a quite huge battery backup and a solar panel, so the battery can charge if there is no voltage on power line, that can keep the system up even if the power line is down for very long time (we have another, older, system developed on AVR chip that went offline after 72 day of no voltage on power line, with solar panel partially covered by snow and with cloudy sky). So I've implemented a variable stored in nonvolatile memory that tells the system that the previous reset was due to a user input or loss of power (when battery is low the system will auto sleep and gets waken when voltage restores via int trigger). If the system resets and that variable was not set then it automatically increment an error counter and also triggers a user notification.

 

My issue (basically a hardware issue) that I have to tackle is if I can have 2 Flash modules connected on the same QSPI bus, one in XIP mode and one as a regular flash module, or I have to use one QSPI bus and one SPI bus pass them trough two 1:2 mux so one Flash module is connected as QSPI in XIP mode and one connected as SPI, and be able to run the code from XIP one and on rare occasions update a new version of firmware on the other one.

 

I will add 2 pseudo schematics to illustrate my issue in this thread but for now I'm unable to do so as the site gives me an error when uploading images :(.

 

Any way thank you for the hint.

Last Edited: Mon. Sep 14, 2020 - 11:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So what is the best way to connect the 2 QSPI Flash modules as I need to run the application from one of them using XIP and at the same time be able to upload a new version of the application on the other one and swap them at request or at error/fail of the active one.

 

Should I go with the standard SPI way :

 

 

 

or

 

Should I go with the mux way :

 

 

(It seems that the system is not allowing me to upload the pseudo schematics so I've uploaded the images on web)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you need to do your research and make the decision for yourself. I fail to see why you would need two flash devices - do you really need the storage of two devices? or the more obvious method is to have two (or more) of the code images in flash -if one fails the start up test, then go to the alternate one.

 

I you REALLY want two chips, why would you need a multiplexer? The chip select determines which one would be active, so you really only need logic on that signal - so that brings you back to the first diagram with some logic to determine which one is active.

 

As for the BEST method - only you know the specifics of your application. if you have two devices on the one bus, then only one can be active at a given time. Can your application tolerate that? Identify your constraints and resolve the conflicts. Then you will arrive at the solution. if in doubt - try it. Even if it fails you will have learn something in the process.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What failure mechanisms are considering?

If one device fails by always driving a data signal (high or low) even when the chip select is inactive, then sharing the data bus may be problematic.

 (Note, this should be a rare failure mechanism, but I have seen it occur... YMMV)

Adding multiplexers may complicate the problem by adding more devices with their own failure probabilities.

 

The decision depends on factors you have not presented:

  • product life cycle
  • operating environment
  • the criticality of correct performance
  • etc.

 

If it is just to be able to program and retrieve data from either device and the expected failure is of the flash array itself (and not the peripheral logic) then option A should be suitable.

 

Edit:

Kartman wrote:
only you know the specifics of your application
yes+100

 

David

Last Edited: Sun. Sep 20, 2020 - 12:29 PM