MCU Bootload Peripheral - SPI Master, Not Slave

[jon2]

Hello!  I would like to modify the bootloader to run as SPI master but I'm having trouble determining all the modifications that need to occur to the bootloader.

I have an SPI EEPROM that contains the application that should be run.  I have created an spi_master peripheral. In this spi_master peripheral, the plan is to read the application from the EEPROM, one packet at a time, and provide those packets to the bootloader. I am able to see that the full_init method gets called as expected and I can read from the EEPROM and see the application and metadata correctly.

However, since all the existing peripherals run as a slave, with the external device being the master, I am having trouble understanding what parts of the peripheral interface need to be implemented vs which parts can be removed.  For instance, I don't think I need the IRQ handling portions since I will doing a blocking read from the EEPROM whenever I get data.  I'm not sure if I need the write method, because the bootloader probably doesn't need to write anything back to the EEPROM.

Are there any examples or documentation that address creating a custom peripheral with the MCU in master mode?  Any advice on how best to approach this would also be greatly appreciated.

Thank you!

Jon

[kerryzhou]

Hi Jonathon Smith ,

   What the kinetis chip  you are using now? Please tell me the chip part number, thank you!

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jon2]

It is a K66 on a custom board.  The EEPROM is attached to the SPI2 bus.

[kerryzhou]

Hi Jonathon Smith

  Please refer to the bootloader reference manual:

https://www.nxp.com/docs/en/reference-manual/MCUBOOTRM.pdf 

  There has the detail SPI working flow, but this SPI is used to communicate with other SPI module, not the EEPROM.

  You can refer to it at first, about the customer board, you also can refer to chapter 11.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jon2]

Kerry,

Thank you for your reply!

Unfortunately, chapter 11 only explains how to customize the bootloader configuration and the bootloader as a whole.  This is important information that I need as part of incorporating the custom peripheral into the bootloader.  However, I need to create the custom peripheral first.

The SPI example and workflow descriptions are all geared towards the MCU acting as the slave and some external device pushing packets in. The bootloader then looks at the received data, makes sense of it, then acts appropriately based on the data.  

However, that isn't exactly what I need to do.  I need to read data from the EEPROM, not have it pushed in.  Also, I need to produce wrap the data in the correct sequence of packets so that the bootloader can understand what to do with the data.

So,  does this sound like the general approach I should use?

1. Create a new dspi_master_peripheral (instead of dpsi_slave_peripheral), do the following in the new code

• when there is a new application that should be flashed, set s_dspiMasterActivity[self->instance] = true;
• read the application from the bootloader, one packet at a time
• for each packet of data
  1. create a framing packet
  2. fill the framing packet with a command packet or data packet
  3. push the packet into the received byte queue, so that the pump command will receive the packet

2. Configure the bootloader to use the dspi_master_peripheral

• Following the guidance in chapter 11 of the reference manual you mentioned

If that is generally correct, then the questions are:

1. What is the sequence of command/data packets I would need to send in order to have the bootloader load the application into memory and then execute it?
2. Where in the flow does it make sense to read the next packet of data off of the EEPROM? It seems like I want to create a packet and push it into the receive queue before bl_main.c calls pump each time, if there isn't already a packet available.  Would it make sense to call a method that reads the data and creates a packet in the bootloader_run() method, right before _bootloaderContext.commandInterface->pump();  or is there a better place that is more consistent with the bootloader architecture?

[kerryzhou]

Hi Jonathon Smith,

   Thank you for your updated information.

   Yes, the KBOOT SPI is the slave, actually it needs to connect to another board which will transfer the data as master to the MCU SPI slave.

   So, until now, we don't have the application which you need, then you need to design your application by yourself. Just talk about the thought about it. You need to create the SPI master code, which can do the external eeprom data write and read. Besides, you also need to design the code, which get the app, then write to the eeprom.  But if you have other tool to write the app code to your EEPROM, and you just need to use the K66 read the EEPROM, then you don't need to design the related code. You just need to create the eeprom read code in the bootloader.

   When you want to boot the code which you located in your external eeprom, you need to read the EEPROM code, and write it to the RAM or the internal relocated flash address, then boot from the RAM or the internal relocated Flash.

After the whole app in the eeprom is wrote to the internal side, you need to relocate the vector, SP and PC, just jumper to the app which has wrote to the internal side.

Wish it helps you！

If you still have question about it, please kindly let me know.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------