Issue with Bare-Metal Programming of nRF52-DK

RE: Issue with Bare-Metal Programming of nRF52-DK

Aaron Feys — Mon, 05 Mar 2018 13:34:44 GMT

Hi @MartinBL,

I just tried it with that code, and everything worked! No idea...

Thanks for the help!

Thanks,

~Aaron

RE: Issue with Bare-Metal Programming of nRF52-DK

MartinBL — Mon, 05 Mar 2018 13:29:58 GMT

Seems to work for me. Can you try to read out the GPIO->PIN_CNF[11] register with

nrfjprog --memrd 0x5000072C

before and after you configure the GPIO?

My output is 00000002 before the configuration and 00000303 after, which is the correct configuration.

This code toggles LED_2 on my nRF52 DK kit.

#include "board.h"
#include "basics.h"

int main(void) {
  init(); // Test

  while (1) {
    GPIO->PIN_CNF[18] = ((uint32_t) GPIO_PIN_CNF_DIR_OUTPUT << GPIO_PIN_CNF_DIR_Pos) |
      ((uint32_t) GPIO_PIN_CNF_INPUT_DISCONNECT << GPIO_PIN_CNF_INPUT_Pos) |
      ((uint32_t) GPIO_PIN_CNF_NOPULL << GPIO_PIN_CNF_PULL_Pos) |
      ((uint32_t) GPIO_PIN_CNF_DRIVE_H0H1 << GPIO_PIN_CNF_DRIVE_Pos) |
      ((uint32_t) GPIO_PIN_CNF_NOSENSE << GPIO_PIN_CNF_SENSE_Pos);
    GPIO->OUTSET = (1UL << 18);
    GPIO->OUTCLR = (1UL << 18);
  }

  return 0;

RE: Issue with Bare-Metal Programming of nRF52-DK

Aaron Feys — Mon, 05 Mar 2018 12:17:37 GMT

Hi @MartinBL,

Thanks for your response. That's definitely a step in the right direction! Now, if we change that entire section to:

GPIO->PIN_CNF[11] = ((uint32_t) GPIO_PIN_CNF_DIR_OUTPUT << GPIO_PIN_CNF_DIR_Pos) |
    ((uint32_t) GPIO_PIN_CNF_INPUT_DISCONNECT << GPIO_PIN_CNF_INPUT_Pos) |
    ((uint32_t) GPIO_PIN_CNF_NOPULL << GPIO_PIN_CNF_PULL_Pos) |
    ((uint32_t) GPIO_PIN_CNF_DRIVE_H0H1 << GPIO_PIN_CNF_DRIVE_Pos) |
    ((uint32_t) GPIO_PIN_CNF_NOSENSE << GPIO_PIN_CNF_SENSE_Pos);
GPIO->OUTSET = (1UL << 11);

You'll notice that it doesn't work again! I don't understand! The definition of those register types have all volatile members.

Thanks,

~Aaron

RE: Issue with Bare-Metal Programming of nRF52-DK

MartinBL — Mon, 05 Mar 2018 08:58:15 GMT

Hi,

I tested your code and saw the same behaviour. Adding the 'volatile' keyword to *ptr seemed to fix it.

volatile uint32_t* ptr = (uint32_t*) 0x5000072C;

I'm no compiler expert so I can't explain why though. I just a had hunch.