modifying nrf_spim p10056 to a p10056e build

RE: modifying nrf_spim p10056 to a p10056e build

Jørgen Holmefjord — Wed, 18 Sep 2019 07:28:05 GMT

I agree that the PRS module is not very well documented. You can see which box is used for sharing witch peripheral, for each chip, in the nrfx_prs.h header file.

RE: modifying nrf_spim p10056 to a p10056e build

Julian — Wed, 18 Sep 2019 06:45:43 GMT

thanks for the answer..

When I get some time, I'd like to dig into what the difference is between the config for a uart project and the blinky project for the same target, I'm sure it'll be instructive to see what difference makes some defines for the bsp button handling code fall over in a screaming heap.

I had a quick search, but haven't been able to find much info on what these PRS_BOX values even mean? letalone why I need to set one of these for a particular chip but can't for another. the SDK help files for the whole PRS are particularly frustrating in describing each setting as... itself.....

Anyway - since asking this question, I decided that the 52811 isn't for this project.

Having no room to compile a debug version of the firmware, before I had even started any dev beyond configuring some on chip peripherals and the BLE radio from a sample skeleton project that does nothing....... well, that seems to be asking for trouble.

I've got an nRF52-DK and some eval boards for the parts the custom board was using, and now I'm progressing on the 52832...

RE: modifying nrf_spim p10056 to a p10056e build

Jørgen Holmefjord — Thu, 12 Sep 2019 09:32:45 GMT

Hi,

I tested porting the nrfx_spim example to pca10056e and I did not face any BSP related errors, however, I used a different approach than you did. I copied the pca10056e projects from uart example into nrfx_spim example, copied sdk_config from pca10056 directory into pca10056e directory, and added the missing source files required by the nrfx_spim example. I also face the multiple UART handler error, but this can easily be fixed by setting NRFX_PRS_BOX_2_ENABLED to 1 in your sdk_config.h file (fewer peripheral instances on nRF52811 cause less required resource sharing boxes, in nRF52811 box 2 is used for UART/UARTE, while box 4 is used in nRF52840).

Attached project: devzone.nordicsemi.com/.../nrfx_5F00_spim_5F00_pca10056e.zip

Best regards,
Jørgen

RE: modifying nrf_spim p10056 to a p10056e build

Julian — Thu, 12 Sep 2019 02:10:12 GMT

Failing an actual resolution to this exact issue... is there any recommended approach for just throwing out the SDK completely (or partially?) and writing my own drivers for the peripherals I need, while still being able to configure and use a softdevice, and not stepping on any shared resource requirement's toes?

RE: modifying nrf_spim p10056 to a p10056e build

Julian — Thu, 12 Sep 2019 02:09:22 GMT

FYI... just modified a TWI example project from scratch to work for emulated 52811 on 52840-DK, and had exactly the same problem. (project needs TWI too, and I wanted a sanity check that i hadn't made a mistake in translating the Segger Embedded Studio project file)

Also, note that if I continue to hack bsp.c so it at least compiles (putting in the same rules to block out code that depends on that define, as the define has!) the next problem I get is that the linker doesn't link, because I get a multiple definitions of UARTE0_UART0_IRQHandler

Here's the hacked bsp.c file from the SDK that gets me to the definition collision for the linker, in both the TWI example port I'm trying to do, and the SPI example port I was trying to do yesterday.

devzone.nordicsemi.com/.../bsp.c