nrf5340 Low Level Programming

[AMarch]

From what I can see so far, it appears that the application processor flash is at 0x00000000 - 0x00100000 and the network processor resides at 0x01000000 - 0x01040000.

If I were to relocate code I wrote for an nrf52840 to the  0x01000000 - 0x01040000 region, AND fix up the base locations of the peripheral devices I used, is it reasonable to expect that I could run this firmware on the network processor?

The base libraries I cloned from here github.com/.../nrfx.git seem to suggest the possibility, if I overlay them into the current nrf52 library set perhaps.

Additional observations:

Looks like some of the nrfx set of files has a few new items , for example the FICR is broken out into secure and unsecure mapping, it seems. The library uses these names like FICR_NS but doesn't appear to actually define them any place. So that is will be some work.

EDIT: I found the actual code while writing this, seems I forgot to delete this line.... my fault for point my grep to the wrong directory.

big oops, need to change target to m33 vs m4....not sure how significant the instruction set changes .

[Øyvind]

From what I can see so far, it appears that the application processor flash is at 0x00000000 - 0x00100000 and the network processor resides at 0x01000000 - 0x01040000.

 I agree if you mean that the application processor flash is at 0x00000000 - 0x01000000. 

If I were to relocate code I wrote for an nrf52840 to the  0x01000000 - 0x01040000 region, AND fix up the base locations of the peripheral devices I used, is it reasonable to expect that I could run this firmware on the network processor?

 Don't know if anyone has tried, it may be worth a try. 

The base libraries I cloned from here github.com/.../nrfx.git seem to suggest the possibility, if I overlay them into the current nrf52 library set perhaps.

 Can you please point me to where it suggests this?

Looks like some of the nrfx set of files has a few new items , for example the FICR is broken out into secure and unsecure mapping, it seems. The library uses these names like FICR_NS but doesn't appear to actually define them any place. So that is will be some work.

In modules\hal\nordic\nrfx_config_nrf5340_network.h e.g. FICR is defined:

#define NRF_FICR       NRF_FICR_NS

big oops, need to change target to m33 vs m4....not sure how significant the instruction set changes .

Yes, that's right. nRF5340 has two Arm Cortex M33 cores. Have a look at this comparison between m33 and m4. Note that Arm Cortex M33 is ARMv8-M, while M4 is ARMv7-M. According to Introduction to the ARMv8-M architecture:

The ARMv8-M architecture only supports a subset of the T32 instruction set, with mostly 16-bit instructions. The ARMv8-M architecture with Main Extension supports a wider range of instructions

Kind regards,

Øyvind

[AMarch]

Øyvind said:

The base libraries I cloned from here github.com/.../nrfx.git seem to suggest the possibility, if I overlay them into the current nrf52 library set perhaps.

 Can you please point me to where it suggests this?

The package has the arm_startup_nrf5340_network.s and system_nrf5340_network.c included, so it looks like I could replace them in the build scripts. 
My first trial with this didn't go so well, because of the need for Kiel to have a Nordic Package for the nrf53. I attempted to start with a simple project using the above files, but then found out my demo Kiel program didn't seem to have support for the m33. 

In any case, it looks like I can compile to programs, then generate one .hex file from them . Of course each program needs to be located for each "BASE FLASH" area of the chips, and you need the appropriate network and applications startup files compiled with them.

My hope is this can ne done without too much problem with the trust circuitry.