[Discussion] Q&A - for ESS module

[duaneellissd]

First thanks for pointing the MIV_ESS out to me, I had not seen this before.
First, I am a SW person, I presume the author of the docs and this are HDL person, so your view of the world is a little different then my own.

Please confirm my understanding and my various questions below.

1. Generally the intent is that the MSS is an ADD_ON to the RISCV CPU, adding a base set of peripherals that contain a common set or "bag of parts" commonly needed by a RISCV design.

2) Question about the BOOTSTRAP_BYPASS signal? When would I use or need this in my design? My thinking is this: GDB via OpenOCD might assert the RESET signal to the board via a FLASHPRO5 (ie: PF300 dev kit has a FlashPro5 built in).

I believe the intent is as follows: Step 1 Debugger has downloaded code into the target and Step 2 - now debugger wants to reset the board, Step 3 so debugger asserts the RESET signal while holding the CPU in reset. Step 4, while holding the CPU in reset debugger attaches to CPU and halts the CPU. Sep 5 - This prevents the CPU (and/or hardware) from starting and loading the image from external flash into RAM over-writing the new application the debugger just wrote to RAM.

The above scenario is common with ARM7 and ARM9 and early CortexM series chips.

My assumption is our design should have some type of "jumper" or "dipswitch" that disables the BOOTSTRAP so that the above does not occur.

** My question: ** Is this the correct/intended usage of this signal? If not - please give a few use cases describing when and/or where this feature would be used. The existing documentation is not complete enough to be understood, it says: "This signal disables bootstrap" - sounds like the signal should be tied off in all designs.

3. COMMENT/WISHLIST ITEM - it would be nice if the SPI interface had more then 1 slave select. With the understanding the boot rom must be attached to SlaveSelect 0. Note: Section 9.1 states: As an initiator, supports up to eight target devices (which I think is a copy/paste error)

4. Interrupts from various peripherals - I find no table for the IRQs from various peripherals (ie: SPI/I2C/UART etc) are not hooked up to the PLIC - and please confirm: this must be done external to the MIV_ESS.

[nitindeshpande]

@duaneellissd

Generally the intent is that the MSS is an ADD_ON to the RISCV CPU, adding a base set of peripherals that contain a common set or "bag of parts" commonly needed by a RISCV design.

This is correct. The MIV_ESS is the extended sub-system for the MIV_RV32.

My assumption is our design should have some type of "jumper" or "dipswitch" that disables the BOOTSTRAP so that the above does not occur.

I would agree with this. The BOOTSTRAP_BYPASS signal is provided so that you can bypass the BOOTSTRAP functionality even though the BOOTSTRAP functionality is enabled in the design. The typical scenario would be that you set BOOTSTRAP_BYPASS=1, when you want to load the executable using a debugger to the LSRAM/TCM and step debug. You can also load an executable into the external Non-volatile memory (I2c, spi etc) this way. Once the external NV memory has the final executables stored in it, you can then set BOOTSTRAP_BYPASS=0, so that on every power cycle MIV_RV32 runs the executable from external NV memory.

COMMENT/WISHLIST ITEM - it would be nice if the SPI interface had more then 1 slave select. With the understanding the boot rom must be attached to SlaveSelect 0. Note: Section 9.1 states: As an initiator, supports up to eight target devices (which I think is a copy/paste error)

The CoreSPI in MIV_ESS does support up to 8 slaves as a peripheral.

Interrupts from various peripherals - I find no table for the IRQs from various peripherals (ie: SPI/I2C/UART etc) are not hooked up to the PLIC - and please confirm: this must be done external to the MIV_ESS.

That's correct. The interrupt connections must be done external to the MIV_ESS.

[duaneellissd]

The typical scenario would be that you set BOOTSTRAP_BYPASS=1, when you want to load the executable using a debugger to the LSRAM/TCM and step debug. You can also load an executable into the external Non-volatile memory (I2c, spi etc) this way. Once the external NV memory has the final executables stored in it, you can then set BOOTSTRAP_BYPASS=0, so that on every power cycle MIV_RV32 runs the executable from external NV memory.

a) the handbook/user guide should state this. the current one does not. this will cause a sw developer no end of headaches until they discover why their code will not load

b) a sw developer needs a means to program the board, GDB/openocd cannot program the spi flash (nor i2c). it would be wise for you (microchip) to provide (appnote example) a means to program the spi/i2c flash.

yes i know flashpro can program a spi but look at the process and all of the steps involved flashpro does not know which package pins the customers spi flash is attached to.

simpler solution and an alternative: consider the case where the sw developers app will not fit in uprom (common problem the uprom is tiny) microchip should provide a small modifiable (provide src code) bootloader app that lives in the uprom and is loaded by the MIV_ESS into ram. this small app would copy a larger app from spi or i2c into ram then starts /launches the new larger app, the customer can then adapt the example app as the need to fit their design.

the example app could for example authenticate/decrypt the spi app via the crypto features of the polar fire

[CLappin]

Hi @duaneellissd,

a) the handbook/user guide should state this. the current one does not. this will cause a sw developer no end of headaches until they discover why their code will not load

We will take this on board and add it to the next version of the core and create a discussion post about this.

b) a sw developer needs a means to program the board, GDB/openocd cannot program the spi flash (nor i2c). it would be wise for you (microchip) to provide (appnote example) a means to program the spi/i2c flash.

We have a bootloader program that may help you with this. Please find it here

Thanks,
Ciaran

[duaneellissd]

The CoreSPI in MIV_ESS does support up to 8 slaves as a peripheral.
that might have been your intent or belief however thats not how it exposes it self in the gui, it has a single slave select

[interrupts are hooked up externally]
i presume the dma requests are the same idea, it would be good to show some examples of both irqs and dma requests in the hand book.

[CLappin]

The CoreSPI in MIV_ESS does support up to 8 slaves as a peripheral.
that might have been your intent or belief however thats not how it exposes it self in the gui, it has a single slave select

CoreSPI was integrated into MIV_ESS for Bootstrap purposes and was limited to a single slave on that basis. We will look into enhancing in a future revision. For now, a CoreSPI can be used for Multi Slave applications.

i presume the dma requests are the same idea, it would be good to show some examples of both irqs and dma requests in the hand book.

we can add this to the handbook for the core in the next release.