Crash when handling NFC events with Web IDE connected

[espruino-discuss]

Posted at 2017-05-07 by atkinchris

I'm experiencing an issue with my new Puck when using it's NFC while connected to the Web IDE.

While the Web IDE is connected to the Puck, if my phone attempts to read the Puck as an NFC tag, after one or two successive reads, the Puck will appear to crash. It will no longer be seen as an NFC tag by the phone, and the Web IDE will either disconnect automatically, or realise it's disconnected after trying to issue a command. I won't be able to detect the tag, or see it again in the Web IDE, until the battery is reinserted.

If I upload the code, save it, disconnect the Web IDE (and lift the battery on the Puck) the NFC tag will be correctly identified - and does not crash, even after a many successive reads. (Uploading the code and scanning the Puck without lifting the battery often meant the tag was not detected)

My example code:

NRF.on('NFCon', () => print('Hello world!'));
NRF.nfcURL('https://www.google.com');

When the Web IDE is connected, I see a few print messages - but after 4 or 5 messages, the terminal output stops half way (Hello wo) - and the Puck crashes. I don't have any issues with other functions when connected to the IDE, such as printing a message when the button is pressed, or setting LEDs.

Has anyone else experienced issues with unreliable NFC behaviour when connected to the Web IDE?

Web IDE is running on a Macbook, using Chrome 58 and the internal Bluetooth.
Phone is a Nexus 5X, using Chrome to automatically open the URL in the NDEF message, and the "NFC Tools" app to read the Puck.
Puck is running the latest firmware available at the time of this post, 1V92.

[gfwilliams]

Posted at 2017-05-08 by @gfwilliams

Strange - so you're saying that something like this:

NRF.on('NFCon', () => LED.set() );
NRF.on('NFCoff', () => LED.reset());

is fine - it's just when you print text from the NFCon event that you have problems? And the Web IDE stays connected - it just no longer prints anything. What if you disconnect and reconnect?

If you type LED.set() on the left-hand side when it's not working, does the LED still light? It might be that it's transmission from Puck.js that has broken somehow, rather than a complete crash?

I'd also be interested in whether:

NRF.on('NFCon', function() {
  setTimeout(function() {
    print('Hello world!')
  }, 1000);
} );

works - so printing, but not right at the same time that NFC starts.

[espruino-discuss]

Posted at 2017-05-08 by atkinchris

It still experiences crashes when there's no print command but is connected to Web IDE (print was the easiest for me to see in the browser, and to get readable messages). Using LEDs, but keeping it connected to the Web IDE, causes it to crash after a few repeated reads.

Immediate commands work in the left pane - but not after it's crashed. Once it's crashed, it either disconnects immediately, or the Web IDE doesn't realise it's already disconnected until I try to issue a command.

Your example with setTimeout doesn't cause the Web IDE to crash.

[gfwilliams]

Posted at 2017-05-08 by @gfwilliams

It's strange - I've just tried again here with exactly your code and it seems to work great for me. I've done it probably 30 times now and it's rock solid.

Please can you check Puck.getBatteryPercentage()? It's about all I can think is different unless your phone reads NFC slightly differently to mine.

[espruino-discuss]

Posted at 2017-05-08 by atkinchris

>Puck.getBatteryPercentage()
=95
>

So you get a print line every time in the Web IDE?

[gfwilliams]

Posted at 2017-05-08 by @gfwilliams

Looks fine then - that is strange. I'd be interested to see whether anyone else hits this? I'm using an old Nexus tablet so it's possible that different devices do NFC differently and can cause problems.

So you get a print line every time in the Web IDE?

It's the device itself. Every command that is executed in the command prompt has the result of evaluating it returned with an = on the left hand side. It's a bit like node.js.

[espruino-discuss]

Posted at 2017-05-09 by atkinchris

Playing with this more, crashes appear to be more common when the reader is removed, such as tapping the phone against the Puck then lifting it again.

Doing this with digitalPulse(LED3, true, 300) being called in response to the event, I managed to get the Puck to crash with the LED remaining on until the battery was pulled.

[gfwilliams]

Posted at 2017-05-09 by @gfwilliams

Wow, interesting - thanks! So you're doing this?

NRF.on('NFCoff', function() {
  digitalPulse(LED3, true, 300);
} );

How many attempts does it take before you get a crash?

And this is on your Nexus 5x? have you tried any other NFC reading devices?

[espruino-discuss]

Posted at 2017-05-10 by atkinchris

I've tried the Puck this evening with a N3DS - it reads the Puck (although it can't do anything with it) and I can see the print output with no crashes.

[gfwilliams]

Posted at 2017-05-11 by @gfwilliams

Very interesting - thanks for checking with another device!

I guess it's time for a phone upgrade then... However if @AnticaT can reproduce with the bare Nordic NFC example (mentioned in the other thread) then we can go to Nordic with it, as it looks suspiciously like a problem with their NFC implementation.

[espruino-discuss]

Posted at 2017-05-11 by atkinchris

I've tried @AnticaT's FW with similar code (NFCrx rather than NFCon) - the crashes are the same when the tag is scanned.

[gfwilliams]

Posted at 2017-05-11 by @gfwilliams

Yeah, I'm pretty sure it's an error internal to the NFC library - so no matter how it's used there would still be the problems. Much like me with Espruino, Nordic (the chip makers) find it hard to help if I just say 'it's not working with my code'. If I can show their simple NFC example code is broken then they'll be able to help though.

If you (or anyone else) finds other devices that definitely work or definitely cause problems, please could you post them up?

Works

Nexus 10
Nintendo 3DS

Doesn't work

Nexus 5X

Also, is there anyone in the UK that would be willing to lend me their Nexus 5X to test with? I could then test it with the nRF52 Devkit.

[espruino-discuss]

Posted at 2017-05-11 by atkinchris

Which app were you using with your Nexus 10 to test @gfwilliams? I used both NFC Tools and NFC TagInfo by NXP, the latter of which created far more NFC events.

With both apps and @AnticaT's FW, I can see Select CL1 commands reaching the JS event system (would have expected these to be handled and not propagated).

[gfwilliams]

Posted at 2017-05-11 by @gfwilliams

I literally just turned on NFC on the N10 and used the OS's scanning capability.

Does the N5X work when you do the same? Or does it only cause problems when you run one of the other apps?

[espruino-discuss]

Posted at 2017-05-11 by atkinchris

Just using the NFC to launch the browser with an NDEF URL seems slightly slower than a real tag - but it doesn't crash the Puck.

[gfwilliams]

Posted at 2017-05-11 by @gfwilliams

Ok, so actually in your case N5X works just fine normally - it's just when you use a special app on the N5x that there's trouble?

[espruino-discuss]

Posted at 2017-05-11 by atkinchris

Yep - any app that tries to read more from the tag than just it's basic NDEF message.

[gfwilliams]

Posted at 2017-05-11 by @gfwilliams

Is this with the normal firmware, or the @AnticaT one?

So both NFC Tools and NFC TagInfo can trigger problems, but only when trying to handle NFCon and NFCoff events? I guess it might be a way for me to reproduce it here with the Nexus 10.

[espruino-discuss]

Posted at 2017-05-11 by atkinchris

Both - I was using NFCon events in 1v92 (downloaded from here https://www.espruino.com/binaries/) and NFCrx in AntiCat's.

NFC TagInfo gives me more information on a tag - and was much easier to trigger crashes with.

[espruino-discuss]

Posted at 2017-05-24 by AntiCat

I think, I've identified the possible source for this issue Source:

/* Take into account only number of whole bytes */
uint32_t rx_data_size = ((NRF_NFCT->RXD.AMOUNT  ...) - NFC_CRC_SIZE;

In some cases NRF_NFCT->RXD.AMOUNT is 0. 0 - NFC_CRC_SIZE with unsigned datatype results in a very large number.

Btw: I also don't like that nordic is accessing data from this buffer without verifying, that the received amount of data makes some sense:

if(m_nfc_rx_buffer[0] == NFC_SLP_REQ_CMD)

[gfwilliams]

Posted at 2017-05-25 by @gfwilliams

Wow, that's great. And it makes sense that the third-party app could be triggering problems.

Have you tried adding some checks and seeing if that fixes it?

[espruino-discuss]

Posted at 2017-05-25 by AntiCat

Yes, my branch is more stable now. However I'm not sure if I found the error @atkinchris had.

The issue I fixed is definitely independent of the two former issues BLE on/off and can't stop and start NFC more then once.

Attachments:

• 0013-NFC-HAL-Fixed-integer-underflow.patch

[gfwilliams]

Posted at 2017-05-25 by @gfwilliams

Great, thanks! I've just pulled that in - hopefully that'll fix some problems.

I didn't check, but I wonder if Nordic have made some improvements in the newer SDK that could be ported back.

[espruino-discuss]

Posted at 2017-05-25 by AntiCat

The code in newer SDKs looks significantly cleaner, they removed all the workarounds for silicon prototypes. I can't tell if they fixed anything.