Search results for:

ping keep alive

ping keep alive

While I'm searching for a suitable gdb tutorial or suggested command line instruction set,

I have made a bit of progress with attaching the gdb process, but I'm not sure this is going to get me to setting breakpoints within the .c source, similar to how one might debug a Visual Studio C#/C/CPP project.

From the web page content, link post #1, my mental model is that the .c source seen within the VSCode app would be the launch point to start a main.c file there. Several failed attempts at tasks.json and launch.json
left me a bit bewildered, and had gotten to the hardware debug stage with SEGGER and SWD. This still seems to be the subsequent next step, before gaining the experience debugging with the Espruino Linux executable, which should be first, shouldn't it?


For example, should I need to set a BP at (inside fcn):

L958 jshardware.c
JsSysTime jshGetSystemTime()

what is the process to get from Javascript instruction

https://www.espruino.com/Reference#l__gl­obal_getTime

presumeably run from the Espruino Linux exectuable running inside the VSCode Terminal, through to the call

jswrap_interactive.c#L362 on to the call to jshGetSystemTime()

Still seeking the solution there, maybe sample tasks.json and launch.json are needed, but in the meantime:

Entry point: 0x26554
        0x00026000 - 0x0006ace0 is .text
        0x0006ace0 - 0x0006ad10 is .sdh_ble_observers
        0x0006ad10 - 0x0006ad30 is .sdh_soc_observers
        0x0006ad30 - 0x0006ad50 is .sdh_state_observers
        0x0006ad50 - 0x0006ad60 is .sdh_stack_observers
        0x0006ad60 - 0x0006ad68 is .sdh_req_observers
        0x0006ad68 - 0x0006ad7c is .nrf_queue
        0x0006ad7c - 0x0006ad84 is .ARM.exidx
        0x20003720 - 0x200039a0 is .data
        0x200039a0 - 0x200039b4 is .fs_data
        0x2003fff0 - 0x20040000 is .noinit
        0x200039b8 - 0x200332d0 is .bss
(gdb) nexti
0x000140d4 in ?? ()
(gdb) nexti
0x000140d6 in ?? ()
(gdb) nexti
0x000140d8 in ?? ()

https://www.gnu.org/software/gdb/documen­tation/

Although I'm not entirely certain at how to interpret the above, it appears the .elf file is being decoded and it appears the instruction(s) is being stepped into, until I learn the gdb commands, am I on the right path to get at the source? The above seems more of a hardware register debug process.

Sun 2021.11.21

Goal is to debug within the Espruino Linux executable.

Last code snippet on the AdvancedDebug page produces the above error.

Following the 'Advanced Debug' instructions at:

https://www.espruino.com/AdvancedDebug

'we'd strongly suggest you try and debug a normal Linux executable of Espruino first'

Fixed Under 'Gothchas'
Removed the reference: ''bootloader' : 1' from the board file
Ran make using DEBUG=1

What does work:
The Espruino Linux executable is built along with espruino_2v08.220_pico_1r3.bin and .lst

It is possible to execute Javascript statements within the Terminal window, with the console like emulation, thus debugging Javascript is possible, but the goal is to debug setting breakpoints within that .c source Linux executable.

From the last snippet window on the AdvancedDebug page:

DEBUG=1 PICO_1V3=1 make gdb

produces error: make: *** No rule to make target 'gdb'. Stop.

Reviewing the makefile file, around L700 is a single reference to gdb: export GDB=$(CCPREFIX)gdb
Reviewing the make files within the folder \make doesn't reveal a gdb make target file.

I tried the second to last snippet:
DEBUG=1 PICO_1V3=1 make flash
make/sanitycheck.make:16: *** You now need to build with 'BOARD=PICO_R1_3 make'. Stop.

which produces an apparent modification that needs attention.

I did locate this sanity check, and attempted to follow the established pattern.

From sanitycheck.make, references indicate to use the 'BOARD=' prefix, so tried that:

DEBUG=1 BOARD=PICO_R1_3 make gdb

but without success. Is there a missing gdb make file that is needed here? Is there a gdb entry point that needs to be included, maybe in a separate make routine or file?

Back to trying this @fanoush arm-none-eabi-gdb suggestion:

post #3 last pp. Conceptual comments needed on simple firmware debug

'What else is empowered to remove spaces?'

Maybe we are splitting hairs here, but doesn't a parser read the user command and break up into the individual pieces without spaces that are processed in order to determine the command syntax for execution? As I understand the process of minification reduces each part to it's simplest representation, the examples in post #1 are already minified as best they can be aren't they?

Should one remove that whitespace, syntax errors occur and the editor points this out with a red 'Bad assignment' error.

When uploaded:

Uncaught SyntaxError: Got ')' expected EOF
 at line 1 col 21
x = () => print(2 --1);

and this syntax without the space is parsed and executes just fine:

z = () => print(1 -(-1));

=function (undefined) { ... }
>z()
2
=undefined

In any event, as I don't receive the errors that are indicated in post #1 using the emulator, I'm wondering what the differences are in browser and PC environment by comparison.

As an end user like yourself, I've just gotten running and are working through the Advanced Debug documentation and this would be a good sample to use to locate the problematic area.

https://www.espruino.com/AdvancedDebug

Am willing to put in the time to learn, but haven't grasped how to set up the environment to get started, even after following the 'Gotchas' section.

'Thank you @Robin! I've only invested a little time so far, I assumed that sample code I had would work!'

While I won't let the thanks of gratitude inflate my ego, shouldn't the credit go to fanoush instead?

P.S. the sundial response was a hoot!!

Tue 2021.11.02

Title: 'Minification bug: erroneous fusion of operator symbols'

I feel this is more of a parsing issue, rather than a minification issue.

Now I find this very interesting. I first tried using a trusted flashed device 2V08.220 and the native app.

On the right hand editor side, in the left hand margin a yellow warning 'Confusing minuses'

When I upload, and execute function x(), I concur with the same error message.

Uncaught Error: Unable to assign value to non-reference Number
 at line 1 col 8
print(1--1)

Using parenthesis and modifying as follows:

x = () => print(1 - (-1));

The above executes as expected as does the mod() example, but with no error(s):

>x = () => print(1 - (-1));
=function (undefined) { ... }
>x()
2
=undefined
>x => mod(x- -x, 1)
=function (x) { ... }
>x()
2
=undefined

When I run the tests using the online IDE indicating the same version and using either emulator, although the original line of code does also display the orange 'Confusing minuses' warning, those upload without errors also!

2v10.187 (c) 2021 G.Williams

Found EMSCRIPTEN2, 2v10.187
Connected to Emulator

>dump()
=undefined
>x = () => print(1 - -1);
=function (undefined) { ... }
>x()
2
=undefined
>y = () => print(2 + -1);
=function (undefined) { ... }
>y()
1
=undefined
>z = () => print(2 - -1);
=function (undefined) { ... }
>z()
3
=undefined
>

Wouldn't you agree that adding the parenthesis indicates a parsing issue?

No clue why errors don't show in my environment when using the online WebIDE:

Browser Chrome Version 94.0.4606.81 (Official Build) (64-bit) on Windows10 v20H2 19042.1288

Maybe a few more community members can give this a whirl and report in perhaps?

Those from the USA will (should) get this with all the nonsense going on. Comment on video:

As our politicians would like you to believe, 'Everything is fine and you are content with what you have'

I couldn't help myself after viewing the video @yngv126399 I feel you pain after investing all the hours you have.

'I guess this is really for fanoush, but I'll welcome any input.'   holds true

Mon 2021.11.01

PS: Robin, I guess I'm not providing any new insight to you in this post... :\ ...

Your responses are always welcome @allObjects as others that read over these words of wisdom will gain additional insight as you pointed out in the other thread.

@fanoush thank you. I'll respond later this week, out of time this evening. . . .

Mon 2021.11.01

'binaryname' : 'espruino%v_puckjs_minimal.hex',

I see that attribute in file PUCKJS_MINIMAL.py @fanoush , but I'm not sure that will solve my issue. Board name not used as build filename. The above will have a different .hex file output from the original, wouldn't it?
ex: espruino_2v10.123_puckjs_minimal.hex   vs.  espruino_2v10.123_puckjs.hex

Will have more time to test and try that suggestion this weekend.

If I wasn't clear, I have a new file nRF52840DONGLE2.py

with specific desired .hex name definition:

 'binary_name' : 'espruino_%v_nrf52840_dongle2.hex'

and using these lines to build:

make clean
source scripts/provision.sh nRF52840DONGLE2
make clean make
make clean && BOARD=nRF52840DONGLE2 RELEASE=1 make

so I expect the output build would produce a .hex file with this new '2' suffix,

et the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
python scripts/check_elf_size.py nRF52840DONGLE2 espruino_2v08.220_nrf52840_dongle.elf
Testing espruino_2v08.220_nrf52840_dongle.elf for nRF52840DONGLE2
STORAGE: 872448 -> 913408
FS DATA: 456396 -> 456416 (20 bytes)
CODE: 155648 -> 456416 (299872 bytes)
Code area Fits before Storage Area
arm-none-eabi-objcopy -O ihex espruino_2v08.220_nrf52840_dongle.elf espruino_2v08.220_nrf52840_dongle.hex
Merging SoftDevice
python scripts/hexmerge.py /mnt/c/Users/robin/Espruino/targetlibs/n­rf5x_15/components/softdevice/s140/hex/s­140_nrf52_6.0.0_softdevice.hex 
espruino_2v08.220_nrf52840_dongle.app_he­x -o espruino_2v08.220_nrf52840_dongle.hex

However, as can be seen by the build output, the .py filename nRF52840DONGLE2 is picked up as you suspect it should, but the internal .hex file definition that I supply within that file, still outputs a filename that isn't desired. (no '2' suffix)

From:

 'binary_name' : 'espruino_%v_nrf52840_dongle2.hex'

Shouldn't it be as I define with the %v substitution:

espruino_2v08.220_nrf52840_dongle2.elf
espruino_2v08.220_nrf52840_dongle2.hex

and not, which is being built? (missing 2 suffix)

espruino_2v08.220_nrf52840_dongle.elf
espruino_2v08.220_nrf52840_dongle.hex

Maybe there is a pre-defined cache list of acceptable board names somewhere, even though this one isn't an original Espruino?

Sun 2021.10.31

Following 'Gotchas' at:

https://www.espruino.com/AdvancedDebug

https://www.espruino.com/Debugger
'it is available for all official Espruino boards.'

While I read over the docs for the above advanced debugger, Segger, Python, WSL, Make, openOCD and SWD it has become quite clear that the Espruino command debugger; may (most likely) not work for the nRF52840 DONGLE as that board is not an Original Espruino.

I've made attempts at modifying the .py file pin definitions and have created a successful build. However, after flashing to the device, I continually receive 'not defined reference errors', despite the pin label is in fact there and mirrors the one in the nRF840DK board file.

Uncaught ReferenceError: "D13" is not defined
 at line 1 col 15
digitalWrite( D13, 1 )

I'm not able to get this to work, although it might be related to this post that will need a response first.

Where should constant PROJ_NAME be changed

I also note that jspininfo.c is not updating correctly.

So, in order to create a simple task for a learning experience, I need to be able to issue a .js digitalWrite() command and then use for instance, openOCD to peek at the registers, and compare that detail with the chip .pdf doc.

the instructions at https://www.espruino.com/AdvancedDebug require a bit of implied knowledge awareness

My initial debug test case would be to create a new definition for say LED13 that actually toggles an external pin, that could be monitored with a VOM or scope, while simultaneously single stepping through using SWD with either the Segger tool or openOCD, or a combination of both. The single command digitalWrite() would be issued using the WebIDE, then take a peek at registers using the above described tool(s).

Conceptually, is this the correct approach?

Should it be necessary to run through pinutils.py or related files, is this done by using Python at the command line, similarly to how one would browser debug a .js or .php file?

Just stumbled across

#define JS_VERSION "2v08"

in jsutils header. The minor version should be near. ;-)

So, Q1 is self answered although I'm not sure how %v is populated

Sun 2021.10.31

Just found:

L714

PROJ_NAME=$(PROJECTNAME)

of file Makefile (no extension) has an assignment, but constant PROJECTNAME is not in the nRF file either.

Sun 2021.10.31

Have read over:

https://github.com/espruino/Espruino/blo­b/master/README_Building.md
https://github.com/espruino/Espruino/blo­b/5503e6bc06562fdffa4e0c13f5bf11228656d2­ec/README_BuildProcess.md#oddities

The current make build file 'CURRENT_BOARD.make' is dynamically built using additional input from
file (in my case) nRF52840DONGLE.py

Generated with scripts/get_makefile_decls.py nRF52840DONGLE
BOARD=nRF52840DONGLE
DEFINES+= -DnRF52840DONGLE
PROJ_NAME=espruino_2v08.220_nrf52840_don­gle

It contains a constant PROJ_NAME which seems to be built from this line

'binaryname' : 'espruino%v_nrf52840_dongle.hex',

I can see that the current build version 2V08.220 gets inserted using the variable %v

No PROJ_NAME constant is within that file.

The constant BOARD seems to be picked up from

'name' : "nRF52840 Dongle",

after removing the whitespace.

When I change the 'binary_name' to the file name I'd like to create, both the .elf and .hex files remain espruino_2V08.220_nrf52840_dongle.elf
and not the file name I place there. This has the unwanted side effect of writing over the official build.

Q1: Where does the version get picked up from?
Q2: Where/how should the PROJ_NAME be set?

Sun 2021.10.31

'It is however possible that at some point you followed some steps you found on the forum or googled that would have permanently installed the compiler.'

Thanks @Gordon, that worked.

Had I not taken extensive notes during this recent VSCode revitalization, it is unlikely I would have discoverd how gcc gets installed.

The day I re-cloned the Espruino repository, I upgraded nRFConnect which forced the install of the SDK15 for the nRF52 chips, and also upgraded make, nrfutil, and esptool to get the latest versions.

During the process of upgrading the above, (maybe during some future install - which one)

this warning popped up:

'The program 'arm-none-eabi-gdb' is currently not installed. You can install it by typing:
sudo apt install gdb-arm-none-eabi'

I followed the instructions:

sudo apt install gdb-arm-none-eabi

which unpacks and installs (around thirty lines in)

Get:2 http://archive.ubuntu.com/ubuntu xenial/universe amd64 gcc-arm-none-eabi amd64 15:4.9.3+svn231177-1 [17.3 MB]
8% [2 gcc-arm-none-eabi 1,871 kB/17.3 MB 11%]

So, future firmware builders, beware when upgrading nRFConnect to build for nRF52

Sun 2021.10.31

https://github.com/espruino/Espruino/tre­e/master/src

Contains the .c source to generate the mechanics/functionality

https://github.com/espruino/Espruino/tre­e/master/scripts

the logical repository folder name contains the .py build instructions, not .js scripts

https://github.com/espruino/Espruino/blo­b/master/libs/network/jswrap_wifi.c

the metadata describing each of the callable functions

Sun 2021.10.31

Thank you for responding @allObjects.

Maybe my question should be where is the underlying Http/Wifi Javascript source (or any internal module) and it's corresponding minified resultant code block that is returned to the WebIDE when viewed using dump()?

In comparrison,

Should I load the 'GPS' module that is available as two sources:

http://www.espruino.com/modules/GPS.js
http://www.espruino.com/modules/GPS.min.­js

the WebIDE will (based on settings) fetch the .min.js file first, which when exposed using a browser will show the underlying content when using dump().

var gps = require("GPS");
Serial2.setup(9600,{tx:A2,rx:A3});
 gps = gps.connect(Serial2, function(data) {
 console.log(data);
})

and when viewed using dump()

var gps = {
  "line": "",
  "#online": function (a) {
  var c;if(c="GGA"==a.substr(3,3)){c=a.length;­var d=0;for(let e=1;e<c-3;e++)d^=a.charCodeAt(e);c=parse­Int(a.substr(c-2),16)===d}c&&(a=a.split(­","),c=a[2].indexOf("."),d=a[4].indexOf(­"."),f({time:a[1].substr(0,2)+":"+a[1].s­ubstr(2,2)+":"+a[1].substr(4,2),lat:(par­seInt(a[2].substr(0,c-2),10)+parseFloat(­a[2].substr(c-2))/60)*("S"==a[3]?-1:1),l­on:(parseInt(a[4].substr(0,d-2),10)+pars­eFloat(a[4].substr(d-
2))/60)*("W"==a[5]?-1:1),fix:parseInt(a[­6],10),satellites:parseInt(a[7],10),alti­tude:parseFloat(a[9])}))
}

Comparing the two, it can be seen that function(a) is the same code that resides in the .min.js file in the online modules folder. The human readable corresponding .js file then, may be used to cross reference.

How does one do the same task for the internal modules? (neopixel, wifi, http) etc.
e.g. where is the human readable source and where/how does that become minified such that using dump() reveals the output as in post #1 ?

Sat 2021.10.30

Using both the native app and the online WebIDE, even when minification is turned off in settings, an internal module request (as in this instance) is returned minified.

var wifi = require("Wifi");
wifi.connect("2WIRE", {password: "3321205"}, function(err){

Results of dump()

var wifi = {
  "connect": function (a,b,c) {
  var d="";c=c||function(){};void 0!==b.password&&(d=b.password);u(k.CLIEN­T,function(b){if(b)return c(b);f.cmd("AT+CWJAP="+JSON.stringify(a)­+","+JSON.stringify(d)+
"\r\n",2E4,function m(a){if(0<=["WIFI DISCONNECT","WIFI CONNECTED","WIFI GOT IP","+CWJAP:1"].indexOf(a))return m;"OK"!=a?setTimeout(c,0,"WiFi connect failed: "+(a?a:"Timeout")):setTimeout(c,0,null)}­)})
},

From

http://www.espruino.com/Reference#Wifi
I am able to locate the .c source that is used to generate the wrap container
https://github.com/espruino/Espruino/blo­b/master/libs/network/jswrap_wifi.c#L207­

I'm struggling with how the WebIDE is returning minified code, when those options are turned off.

Is it that the internal modules are minified and included within the .hex .elf build, such that accessing them is returned as such, (in this case is there a location of the minified .js source at GitHub?)

or,
Is it that the .js content is run through the Esprima minifier real time when the .connect() (in this instance) function is called,

or, . . . other??

Note: I still haven't been able to run successfully an openOCD session to peek into these files.

Wed 2021.10.27

'Looks like global variables named c are a no-go in Espruino 2v10'

I believe there are several/many others as I demonstrated in several code block examples over 18 months ago:

http://forum.espruino.com/conversations/­346667/#comment16244096

Those should provide useful for eliminating the other letters of the alphabet.

Wed 2021.10.27

I am not appending to this thread with the intent to solve the original post #1 inquiry.

What was attempted to be solved then was a result of chasing the symptom, and not the actaul cause as I shall explain.

It became evident that the way in which the Trace output behaved was a direct result of the corruption caused by the underlying task that has just recently resurfaced again.

re: 'It's not 10 lines of code. It's at least 700 lines of very dense JS.'

It is amazing that 18 months have elapsed and no others have stumbled across what I spent many weekends of countless hours testing and documenting then, that is until now.

@skm recent post again reported this discovery

using c.test in E.showMenu

The endless anomaly above occurs after my source gets clobbered just using the Wifi or tinyMQTT module functions in a similar manner to how @skm did in the above thread link.

It appears that user defined single character function names and var declarations are affected. In the following link, several single char objects up to letter 'f' get clobbered, so my hunch is that it is for all letters of the alphabet that minification may produce it's own instance. From using Google's closure compiler, I've had the full range of the alphabet in resultant output, so this is quite possible.

Back on Sun 2020.04.26, I had provided unique example code snippets using the Wifi module demonstrating this:

Sanity check for Wifi and http modules please getIP getAPIP

and another

Multiple occurances during a trace() output

Which included an example using a Wifi method in post #4 with steps to reproduce.

post #4    code blocks to create the anomaly

You'll note that I pared down the snippet to a basic example that coincidentally has the same single char function that gets clobbered when those moudles are loaded as did @skm in his example.

I even filed a issue #1811 with an exact descriptive title on Sun 2020.05.03 which was dismissed

Issue #1811

Anomaly in deployed module corrupts user namespace global scope

Interesting how one may be blinded by simplicity and incorrect conclusions drawn while observing the symptom and not the cause.

It appears what I discovered then is now understood.

Wed 2021.10.27

'The provision script does not permanently install GCC'

This is a good tid-bit of detail related to my specific issue.

I got as far as openning the provision script and found

        if [ ! -d "gcc-arm-none-eabi-8-2018-q4-major" ]; then
          curl -Ls https://github.com/espruino/EspruinoBuil­dTools/raw/master/arm/gcc-arm-none-eabi-­8-2018-q4-major-linux.tar.bz2 | tar xfj - --no-same-owner

and have run out of time to dig deeper.

My plan for the weekend is to run the removal command suggestion provided in post #6 and determine if progress can be made.

Wed 2021.10.27

'While I try and document what's needed in ... I can't document every eventuality'

I'm totally with you here. Upon weeding through all the new terms, what is there is nicely laid out and well documented.

A month ago when I first discovered the previous (2 yrs ago) install wasn't going to cooperate, I had this grandious idea to document step-by-step in order to create a nice pictorial tutorial for Win10 machines.

Four weekends of fun and surprises has exposed the reality that there are too many permutations and combinations of the individuals parts that are required to allow that incredibly complex process to function 100% of the time.

And as you have pointed out, every eventuality is just too complex to create a single tutorial. Each user will have it's own nuances and installed program structure, along with an unknown level of updates that may or may not be current and at the level needed for the scripts to run. The only real way is exactly how I'm floundering right now, just keep asking questions to resolve each hiccup along the way. Painful, . . . and an incredibly steep learning curve.

As your nicely laid out step-by-step process is the simple basic process that will work when understood, it is in fact the better way to get individuals started.

Tue 2021.10.26

You may find this resource of great use @Andreas_Rozek for RGB ordering:

REFERENCE table of RGB Led datasheets

Group discussion around source code

RGBW neopixel leds

Tue 2021.10.26

'it shows me "=undefined" why is that?'

Explanation: see 11 th bullet item

http://www.espruino.com/Troubleshooting

---cont

Before I start making changes;

'So apt get remove arm-none-eabi-gcc I think? Then run provision again.'
'If you don't have anything installed then provision.sh should do it for you automatically.'

If I grasp the intent of the above, the provision script should only install gcc if gcc was not present before the script is run. Am I understanding that correctly?

Under the assumption that is the correct understanding, I Googled a bunch and found this, mildly related tid-bit.

Where is GCC ARM none Eabi installed?
Installing the ARM Toolchain for Windows

Download and run the installer to install arm-none-eabi-gcc and arm-none-eabi-gdb. Select the default destination folder: C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2020-q4-major.

I did not follow those instructions, but did some poking around and along with:

https://gcc.gnu.org/bugzilla/show_bug.cg­i?id=96882

My version is subtlety different than that one mentioned from a year ago, and now

make what I believe to be an astute observation.

History:
Remember, I cloned the repository following the Readme build instructions over two years ago, which after a few weekends was able to get running. I build one .hex file and flashed it just to gain a bit of confidence.

Never touched that install, other than to look at the .c .h source for the Neopixel functions and where they were located.

One month ago, I made an attempt to compile the nRF52 stuff to see if a build was possible, knowing that many changes had occurred and likely would fail. It did.

Made a backup of all the old cloned files there, and followed the step-by-step process that we did two years ago, starting with cloning the current Espruino repoistory.

Now for the astute observation:
Should my understanding that the provision script only installs when a version of gcc is not present, then it is quite possible that the old gcc content is still there. It ran two years ago, but fails now.

What should the current gcc version be?