Using pins D9 & D10 on the MDBT42Q

Hey!

I just wanted to ask if there are any gotchas to know about when using pins D9 & D10 on the MDBT42Q module.

I had a PCB fabricated & I'm trying to use those pins to start i2c communication with another device on the board, but I'm getting some exciting errors.
I noted in the docs it says those pins are used for NFC but I'm not using NFC in my code, could that be causing some weirdness? I'm really hoping the answer isn't "You can't use those pins since they're for NFC"

Cheers!

-J

there is persistent setting in UICR register NFCPINS that must have its lowest bit cleared. Run this peek32(0x1000120c).toString(16); to see if it all FFs or there is zero or FE.

When this is OK then still those pins are not the same as any other. Check this note , there is increased leakage between them so they affect each other.

Morning!
Thanks for your help, I checked that register and it looks like its all FFs, so looks like the lowest bit hasn't been cleared - is it sensible for me to directly modify that register or is there a 'safer' espruino way of doing this?

When a firmware without NFC enabled boots, it clears the UICR registers automatically to enable the GPIO pins.

So actually the easy solution is just to install a firmware with NFC disabled and it'll all magically work - although the official build still has NFC in so we'd have to do a custom build.

@fanoush did you find another way to set UICR register values from Espruino? I see that require("Flash").write(0,0x1000120c) doesn't work.

Are these modules you've got from the Espruino shop, or are you programming your own? If you'd programmed your own it should be pretty easy to do a build yourself, otherwise I can get one sorted for you.

sadly UICR area is not writable when softdevice is enabled, so it is not easily possible without flashing custom build of espruino, it needs -DCONFIG_NFCT_PINS_AS_GPIOS in board file - then it is done automatically as part of application startup.

Or you need espruino with patch that can run your javascript to write to UICR as part of NRF.restart() but that is custom build too. Or it can be done via SWD - openocd or other debugger.

Easiest perhaps is to rebuild espruino for MDBT42Q from source with that one line in board file.

I see that require("Flash").write(0,0x1000120c) doesn't work.

Yes, there is no nordic api for that https://devzone.nordicsemi.com/f/nordic-­q-a/7300/can-sd_flash_write-be-used-to-w­rite-to-the-uicr or https://devzone.nordicsemi.com/f/nordic-­q-a/20864/pattern-for-writing-to-uicr-wh­ile-soft-device-enabled

With that patch I am doing it by poking NVMC

NRF.onRestart=function(){
poke32(0x4001e504,1);while(!peek32(0x400­1e400)); // enable flash writing
poke32(0x1000120c,0xfffffffe);while(!pee­k32(0x4001e400)); // NFC pins as GPIO
poke32(0x4001e504, 0);while(!peek32(0x4001e400)); // disable flash writing
}
NRF.restart();

When you add that patch, can you simply use require("Flash").write, or is it a matter of using poke32 to NVMC?

see that nordic link, they do not allow UICR address area in softdevice flash writing api (even if they possibly could), so only poking NVMC works

Nice - ok, I've just added some code in for that. I didn't merge your code exactly as it was because actually there are some potentially bad side-effects of trying to execute JS in a IRQ (which can happen if you do NRF.restart() and then disconnect from BLE).

So @consolenaut you can now flash a cutting-edge build, then just run the following:

NRF.disconnect();setTimeout(function() { NRF.restart(function(){ LED.set();
poke32(0x4001e504,1);while(!peek32(0x400­1e400)); // enable flash writing
poke32(0x1000120c,0xfffffffe);while(!pee­k32(0x4001e400)); // NFC pins as GPIO
poke32(0x4001e504, 0);while(!peek32(0x4001e400)); // disable flash writing
});}, 1000);

Afterwards you should see peek32(0x1000120c).toString(16) == "fffffffe" and once you reboot the device you'll have the NFC pins available.

Just picking this up now, thanks @fanoush& @Gordon for your assistance!

I've updated my board layout to use two other pins rather than 9 & 10 so this shouldn't be a problem in future, but I'm going to flash the cutting edge build & use the code you shared to get this revision working hopefully.

I'm using a pre-baked module from the Espruino store, can I flash a cutting edge build onto it with the ide similar to how I'd update the firmware normally or do I need a a jlink programmer or something more exciting?

Thanks again!

I've updated my board layout to use two other pins rather than 9 & 10

i've seen a watch (ID107plus HR) where those pins are used as I2c sda/scl and it works. Also in B5 fitness tracker one of them is used as a button and the other one is floating. It can be seen that without any pull set on the other pin it follows value of the button connected to the other pin. so it depends, it can work but maybe using other pins is a better idea. Or using just one of them.

I'm using a pre-baked module from the Espruino store, can I flash a cutting edge build onto it with the ide similar to how I'd update the firmware normally

With the ones sold on the store you're sorted - you just need to connect D0(usually BTN1) to VCC when powering the module on - it'll then appear as DfuTarg and you can update it just like you would with other Espruinos :) http://www.espruino.com/MDBT42Q#firmware­-updates

Just to keep you posted, I flashed the cutting edge build onto the board & ran that code, I'm getting fffffffe when I run peek32(0x1000120c).toString(16) which is great, but when I try to connect to my i2c device I'm getting Uncaught ALLCALLADR!=0xE0 - PCA9685 connected? which is progress but not super encouraging.

There's definitely a chance its either the soldering on the board or some other issue so I'm going to inspect that again first. I've had a previous revision of this board working although using different pins for i2c. I'll try and rule out any soldering or connection issues before taking too much more of your time :)

You also need to E.reboot() or power cycle it.

I've power cycled a couple of times with no luck, and I've checked over all my connections, the soldering is all good, but still no luck, just getting Uncaught ALLCALLADR!=0xE0 - PCA9685 connected?

Do you have any way of getting a volt meter to test those pins and see if the voltage is changing as you expect when using D9/D10.write(...)?

@Gordon Checked with a multimeter, connections all look good, no bridges. Voltage is at ~3.3v on the 2 i2c pins, all the address pins on the PCA9685 are pulled down to ground with a 10k resistor and I'm using address 0x40. I switched out the 10k pullup resistors for 2.7k pullups with no change.

Doing a test with a digital write on each pin - when setting both on/off, both go 3.3v/0v. If I toggle one & not the other, sometimes they bind together, but when they don't I see minor fluctuations on the pin not being set when the other one changes, I'm guessing that'll be the bleed fanoush was talking about.

Is there anything else it makes sense for me to try, or is it time for me to bodge-wire to another 2 pins for i2c on the MDBT42Q? :)

I checked the ID107HR plus pinout again - it is here and it uses both pins for HR sensor but only one of them is in fact I2c

...
8	SI1143_INT
9	SI1143_LED
10	SI1143_SDA
..
18	SI1143_SCL

so if it really doesn't work for you maybe it is not coincidence they have scl on 18 and not 9. Th nordic note says

The pins dedicated to the NFC antenna function will have some limitation when the pins are configured for normal GPIO operation. The pin capacitance will be higher on those (refer to CPAD_NFC in the GPIO Electrical Specification below), and some increased leakage current between the two pins is to be expected if they are used in GPIO mode, and are driven to different logical values. To save power the two pins should always be set to the same logical value whenever entering one of the device power saving modes. Please refer to INFC_LEAK in GPIO Electrical Specification for details.

Only things I can think of are:

• To ensure that the pins are actually in 'high drive' mode...

  peek32(0x50000724)&0x700 == 0x700;
  peek32(0x50000728)&0x700 == 0x700;
  

But I'm pretty sure they should be...

• To try software I2C with var i2c = new I2C(); i2c.setup(...)
  
• To try with a lower I2C bitrate
  
  

But it's possible that because I2C uses pullups, the leakage is actually enough to cause trouble

@Gordon @fanoush thanks for your help again, I'll give those suggestions a try just to answer this if anyone else ever has the same issue :) I've soldered some bodge wires to use i2c on D7 & D8 and all is working perfectly, and I've updated my board design to use those pins to, so all it good now, but I really appreciate the assistance

Hi, I'm trying the same thing to override the NFC function on a MDBT42Q and use just as a straight GPIO. I've just upgraded the firmware to 2V08 and pasted in the code from Gordon... still getting the "ffffffff"value for that register.

Any help would be appreciated.

Ahh, so the problem is that the NRF.restart callback was only added in Espruino after the 2v08 release. If you install a cutting edge build from https://www.espruino.com/binaries/travis­/master/ then you should be fine (or 2v09 or later when they are released!).

NRF.disconnect();setTimeout(function() { NRF.restart(function(){
poke32(0x4001e504,1);while(!peek32(0x400­1e400)); // enable flash writing
poke32(0x1000120c,0xfffffffe);while(!pee­k32(0x4001e400)); // NFC pins as GPIO
poke32(0x4001e504, 0);while(!peek32(0x4001e400)); // disable flash writing
}) }, 2000);

@natman1970 just beware that there is this leakage current between those pins as mentioned above, so it may be practical to use just one of those pins

Thanks for the prompt replies. I've got the zip file downloaded and selected it using the "flash from file" button. I select the correct board in the FIRMWARE UPDATE dialog, press next and then there is no prompt to put into bootloader mode...nothing else happens.
Got round that using the URL approach. firmware is in (IDE confirms that) but still can't set the register? Power cycled it as well... Tried the done var watch as suggested by @fanoush and its set still to zero so something is not working

function READNFC() {
   console.log(peek32(0x1000120c).toString(­16));
  return (0);
}

function SETNFC() {
NRF.disconnect();NRF.restart(function(){­
poke32(0x4001e504,1);while(!peek32(0x400­1e400)); // enable flash writing
poke32(0x1000120c,0xfffffffe);while(!pee­k32(0x4001e400)); // NFC pins as GPIO
poke32(0x4001e504, 0);while(!peek32(0x4001e400)); // disable flash writing
});
}

Here's the IDE...

1 Attachment