Issues with nRF52 Cortex CPU type

[MDF]

Hi there

I'm currently using three different target platforms/boards
#1 : a Nordic PCA10040 - attached to USB
#2 : a UTO-NBL-52A developer board - attached to a J-Link plus, using SWD
#3 : a custom PCB with a nRF52832 chip - also attached to a J-link plus, using SWD

I'm using SES to compile code, currently the ble_app_uart example, because that is similar to what the custom board #3 finally shall do.

I can successfully compile + load code into all three targets using the old "nRFgo Studio" - but debugging only works with targets #1 + #2, trying to use SES to load code into the target and start debugging always fails with a "generic error", but it wont tell me details. I tried similar with KEIL and its much the same there.

Using SES I can successfully connect to J-Link and here's something weird: targets #1+#2 report a Cortex-M4 but target #3 reports Cortex-M0
The hardware design of target #3 is quite simple, very similar to the PCA10040 reference design and the only GPIOs used are for UART Rx/Tx
The chip itself is labled "N52832 / QFAAE0 / 1846IZ".

Any idea why the Cortex-Type is wrong ?
thanks, Matthias

[Jared]

Hi,

Can you verify that the application starts when you flash the custom board, do you see it advertising? What version of SES are you using?

regards

Jared 

Also: nRFGo studio is deprecated, use nRF Connect Programmer instead. 

[MDF]

When flashing the binary file via nRFgo Studio, everything works.

I'm using SES 5.44 (64 Bit)

I just made some tests with the "J-Link commander v6.88a", the command line tool, and this one successfully connects and reports a Cortex-M4 - only SES fails to do so.

This is how it looks like when I hit F5

[Jared]

Hi,

Can you try to delete the JLINK File that is auto created when a debug session is started? You'll find it in the under the SES folder in the project folder. If that doesn't help, could you try flashing another example and see if it reproduces with that?

best regards

Jared 

[MDF]

I found this file, deleted it, but the behaviour is the same

I also tried the example "peripheral / blinky / pca10040 / s132 / ses" - which I consider to be the most simple example of all - but I see the same "generic error"

In this particular HW-design, the pin P0.21/RESET is driven by another µC/MSG430 - but I can measure that reset is not active, is it necessary for J-Link to control reset ?

[Jared]

Hi,

All of our examples has preprocessor definition CONFIG_GPIO_AS_PINRESET defined which means that the RESET pin which is an active low pin will be activated by default. You have to remove the preprocessor definition and erase and re-flash your board to deactivate it. Can you try it and see if it helps?

regards

Jared