Writing firmware binary directly to NVM - SAMD21

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

I am working on a HTTP firmware bootloader. The application will download the latest firmware.bin file from a local server and store it in Flash via NVM.  NVM requires I write a page at a time which is 64 bytes. The problem I am having is when the WINC1500 xplained pro downloads the file, it doesn't receive the bytes evenly. Some packets are less then 64bytes. For example:

 

My firmware file size is 10260k

 

1st packet size: 62 bytes

2nd packet size : 64

3rd packet size: 64
4th packet size: 64
5th packet size: 43
6th packet size: 64

....

last packet: length: 7

 

and so on.  When I write to NVM, I get a lot of empty data e.g. 00 I call 'padding', which I believe is preventing the firmware from loading. So my question is, does having a lot empty data ''padding' effect how the firmware will run?

 

Example. The highlighted sections are "padding" required for NVM.

 

This topic has a solution.

"When all else fails, read the directions"

Last Edited: Mon. May 28, 2018 - 12:20 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your padding will wreck the code! You need to write a function that takes a variable number of bytes and loads them into a 64 byte block. Once you’ve got 64 bytes, then you write that block to flash,reset the index to your 64byte block then load more bytes. Rinse and repeat. You do realise that the flash disappears whilst it is writing? So no code gets executed from flash whilst this is happening. One technique is to download your code to a serial flash chip, then have a small bootloader that reads this and other flags to determine if you need to update the internal flash of the micro.

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

Kartman wrote:
One technique is to download your code to a serial flash chip

 

Thanks - it was second on my list if this didn't work. I am going to take a shot at writing the buffer to do what you suggest. 

 

Kartman wrote:
You do realise that the flash disappears whilst it is writing

 

I am not sure what you mean. Can you elaborate?  Got it. This part of the code is handled on request when a new firmware version is ready...

"When all else fails, read the directions"

Last Edited: Mon. May 28, 2018 - 12:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
You need to write a function that takes a variable number of bytes and loads them into a 64 byte block

 

Thanks again - I ended up using a ring buffer. When the ring buffer had 64 bytes, I would empty the ring buffer and write to flash. Works like a charm. Thx

"When all else fails, read the directions"