-
-
I'm trying to understand the memory management of Espruino.
Puck has 64k RAM of which ~11 kbyte are reserved for softdevice and ~37kbyte are reserved at compile time (data + bss). In turn 32kbyte of bss are the 2000 JSVars. Therefore 16k are left for heap and stack.
Heap seams to be 8k (0x2000bcd0 - 0x2000bcd0).
Stack steams to be 16k, 8k shared with heap (0x2000bcd0 - 0x20010000).Are my calculations correct? Does any one know how much stack and heap is occupied at runtime?
-
-
I've retried:
http://www.espruino.com/binaries/espruino_1v92_espruino_1r3.bin
gives meUncaught Error: Function "openFile" not found!
http://www.espruino.com/binaries/espruino_1v91_espruino_1r3.bin
works, note v91 is 6k larger as v92 -
-
-
-
-
-
After fixing the easy issue (NFC and Crash) I've now revisited this one. I've found a solution. However I hit another strange effect while checking for regressions. I've tried to bisect to find the source, but it seams to be present in stock 1v92 also. After every 2nd or 3rd NFC read, my puck doesn't return to its low power state it keeps hovering a little above 1mA.
I would appreciate if you could check this one on your side.
-
-
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.
-
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)
-
Hi
I'm trying to investigate the NFC issues on my Puck. So I've attached a J-Link using SWD.
The connection is stable and I can flash and debug using JLinkExe.However I'd prefare a more advanced interface with symbol names and so on ;-).
So I switched to JLinkGDBServer and arm-gdb. I'm using the espruino built by
DFU_UPDATE_BUILD=1 BOARD=PUCKJS RELEASE=1 make
. (I've tried ELFs built byDFU_UPDATE_BUILD=1 BOARD=PUCKJS DEBUG=1 make
, but do not fit into flash.)For some reason gdb always tries to accesses the SoftDevice area and in particular 0x00000000 and fails (read protection?) instead of 0x1f000 and up. I assume I'm missing some magic Switch. Any suggestions or a working gdbinit are welcome.
-
-
-
-
-
The Graphics implementation is native C-Code. It should be in in this area: https://github.com/espruino/Espruino/blob/master/libs/graphics/jswrap_graphics.c
-
I've used http://espruino.com/binaries/espruino_1v92_puckjs.zip for my regression tests.
I'm also little busy at the moment, I will try it on the weekend.
Tank you for your effort.
-
Are you using that image, or are you using something that you compiled yourself?
Yes
Are you taking the Puck out of NFC range before changing the tag with NRF.nfcUrl? I wonder whether that could be causing problems...
Yes, but perhaps my reader does not "finish" the transfer properly and the nfc state machine is left in a undefined state.
Do you have any contacts at Nordic who might be able to comment on this?
If not, I'm fine with keeping this behaviour in an unresolved state for the moment. Perhaps we can revisit it when you are not that busy. I haven't changed anything to the start/stop code. So mine should be fine too for most people. However it's a very long stretch as long as we do not know the reason for this anomaly.
-
I had an epiphany: Gordon did you use http://www.espruino.com/binaries/espruino_1v92_puckjs.zip for your tests yesterday? The behaviour seams also to depend on the compiler used.
Some weeks ago I spent one day debugging an issue, that when away, when I upgraded to the GCC defined in your documentation.
-
I'm using a Puck.js 1.0e
- Cold Boot
- IDE-Connect
NRF.nfcURL("http://espruino.com");
Start | End | Src | Data (! denotes | CRC | Annotation ------------|------------|-----|-------------------|-----|------------ 0 | 1056 | Rdr |26 | | REQA 4517504 | 4518560 | Rdr |26 | | REQA 9035488 | 9036544 | Rdr |26 | | REQA 13552976 | 13554032 | Rdr |26 | | REQA 18071472 | 18072528 | Rdr |26 | | REQA 22588960 | 22590016 | Rdr |26 | | REQA 27107984 | 27109040 | Rdr |26 | | REQA 27110228 | 27112596 | Tag |44 00 | | 27560128 | 27564896 | Rdr |50 00 57 cd | ok | HALT 27629472 | 27630464 | Rdr |52 | | WUPA 27631700 | 27634068 | Tag |44 00 | | 27642576 | 27645040 | Rdr |93 20 | | ANTICOLL 27646228 | 27652052 | Tag |88 5f 14 55 9 | | 27660672 | 27671136 | Rdr |93 70 88 5f 1 | ok | SELECT_UID 27672372 | 27675892 | Tag |04 da 17 | | 27684368 | 27686832 | Rdr |95 20 | | ANTICOLL-2 27688004 | 27693892 | Tag |51 9f 5b a2 3 | | 27702464 | 27712992 | Rdr |95 70 51 9f 5 | ok | ANTICOLL-2 27714164 | 27717748 | Tag |00 fe 51 | | <--- and so on --->
RF.nfcURL();
NRF.nfcURL("http://espruino.com");
Start | End | Src | Data | CRC | Annotation ------------|------------|-----|----------|-----|----------- 0 | 1056 | Rdr |26 | | REQA 4516448 | 4517504 | Rdr |26 | | REQA 9034464 | 9035520 | Rdr |26 | | REQA 13553488 | 13554544 | Rdr |26 | | REQA 18070464 | 18071520 | Rdr |26 | | REQA 22588992 | 22590048 | Rdr |26 | | REQA 27106464 | 27107520 | Rdr |26 | | REQA 31624992 | 31626048 | Rdr |26 | | REQA 36142976 | 36144032 | Rdr |26 | | REQA 40662000 | 40663056 | Rdr |26 | | REQA 45178976 | 45180032 | Rdr |26 | | REQA 49697488 | 49698544 | Rdr |26 | | REQA 54214432 | 54215488 | Rdr |26 | | REQA 58733472 | 58734528 | Rdr |26 | | REQA 63251968 | 63253024 | Rdr |26 | | REQA 67768960 | 67770016 | Rdr |26 | | REQA 72287472 | 72288528 | Rdr |26 | | REQA 76805952 | 76807008 | Rdr |26 | | REQA
Note: The trace is reformatted to fit to line length
Some how the NFC peripheral is stuck / offline. The handshake does not even start.
I think its an error in the HAL or how it is used. - Cold Boot
Bluetooth LE: mesh standard is now announced:
https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/le-mesh
see also:
https://www.bluetooth.com/specifications/mesh-specifications