Search results for:

Hi @Manxome,

That's an interesting problem.

Have you updated your firmware from st.com?
They had some problems with default frequencies set to a wrong, low, value until 'recently'. You might have received an out of date one.

Are you using an NucleoF401RE or an NucleoF411RE?
One of the differences between F411 and F401 is the basic frequencies of processors. The bins are different specifically about the frequencies and the ram sizes. Actually that's almost all about the differences.
The 1v71 version is for F401, not F411.
Now, the F411 version, posted as an attachment in this post, was only tested by @ac413 and it might be wrong on timings. I can't test it here since I don't have one.

Here is my test of your code on an NucleoF401RE.
I pushed the blue button, alias BTN1 or C13, approximately once a second.
After the dump(), I waited, see lines 25 and 26, then I tried again more or less once a second: It seems to be correct to me.

Don't hesitate to copy your left pane of the web ide.

>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>echo(0);
=undefined
34.60793133333
NaN
35.795147
1.04880302380
36.89486772619
0.98272696428
38.47629082142
1.45765674999
39.73406741666
1.14529867857
>dump()
setWatch(function (e) {  console.log(getTime());
  console.log(e.time - e.lastTime); }, "C13", { repeat:true, edge:'falling', debounce : 10 });
=undefined
222.45914798809
182.61455511904
224.05011024999
1.48233489285
226.35892582142
2.15741746428
227.08728361904
0.58484489285
227.80201604761
0.54634851190
228.63148809523
0.67798594047
> 

Hello @Manxome,

Well, the decision is 'officially' supporting a non Espruino board is quite clear: No!
Only Espruino boards are officially supported.

Now, I, definitely, can test and debug Espruino embedded in a Nucleo-F401RE board, since, I own one, and do intend to make a useful application out of it.

Have a look at the joined file, 2 posts ahead of yours.
There is a very alpha status for the Nucleo-F411RE 1.72 Espruino and @ac413 seems quite satisfied of it.

The goal of ST was to produce pin/pin replaceable MCUs.
However, there are still internal differences between each family, or even MCU's precise references. It does not simplify the changes to do as a few changes in the parametric figures in *.py board's definition file.
So I think you should not expect every detailed functionality to work unless you actually helped to debug it.

Congratulation, you reached the £50 000 pledged last night...

Ok, I refreshed this thread a bit too late!
Yet, in doubt...

Here is a simple mbed .bin which connects to the console at 9600, N, 8, 1, displays the current Nucleo RTC time and blinks LD2 every 2 seconds.
Try to flash this and check in a terminal to see if you have any driver/configuration problem independently of Espruino itself.

You should see something like this in a terminal.
Date and time are not correct!

Time as a basic string = Mon Dec 16 10:11:42 2013
Time as a basic string = Mon Dec 16 10:11:43 2013
Time as a basic string = Mon Dec 16 10:11:44 2013
Time as a basic string = Mon Dec 16 10:11:45 2013
Time as a basic string = Mon Dec 16 10:11:47 2013
Time as a basic string = Mon Dec 16 10:11:48 2013
Time as a basic string = Mon Dec 16 10:11:49 2013
Time as a basic string = Mon Dec 16 10:11:50 2013
Time as a basic string = Mon Dec 16 10:11:51 2013
Time as a basic string = Mon Dec 16 10:11:52 2013
Time as a basic string = Mon Dec 16 10:11:53 2013
Time as a basic string = Mon Dec 16 10:11:54 2013
Time as a basic string = Mon Dec 16 10:11:55 2013
Time as a basic string = Mon Dec 16 10:11:56 2013

Hello,

I have no problem with Espruino on Nucleo-F401RE board from Ubuntu 14.04 LTS.

I did upgraded its firmware but this has to be done from Windows 8.1.
So the instructions from ST and mbed worked very well and there is no need for Windows once you upgraded your board.

Did you checked that you could flash some mbed simple blink program for this board?
This is a good way to isolate any potential Espruino interpreter problem from st-link connection / flashing problems.
I for once have been unable to flash Espruino and solved this by flashing a simple blink program.

Just in case, I join the 1.72 latest version. This is exactly my last commit's result.
It does solve the last details I had in 1.71: a few, really just 1, characters in the input buffer after reset() or load(). It never was a problem such as you describe.

Now that I think of it, from time to time, I have a problem while flashing Espruino on Nucleo: it doesn't reset properly and the board never takes any keystroke from console, if it ever wants to connect. Usually, this happens when I forgot to disconnect the webIDE or gtkterm before flashing the Nucleo. It even happens with mbed .bin.

The flashing operation, when pasting a .bin file to the NUCLEO directory, gives this:

1. the green/red led flashes for a few, 4-6, seconds,
   
2. there is a 1/2 second pause,
   
3. the green/red led flashes again for a few, 4-6, seconds,
   
4. then there is a wait of 2-3 seconds
   
5. then the small green led LD2 (just under the RESET button see page 50/56) emits a shiny green flash which means OK, this sometimes doesn't happen and this is where I have problems
   
6. Then the reg/green led flashes again 1-2 seconds and ends up with beeing red
   
7. the board reboots.
   
   

If, at point 5 above, LD2 doesn't flash, I wait until the reboot, disconnect the usb cable, reconnect it and just reflash the same .bin and things go well.

From what I read in the docs, it uses MICO which an RTOS + wifi.
They reserved 768 Kbytes for MICO and I suppose some user application among which Espruino could run.
Specifically, there is 384 Kbytes reserved for OTA updates (section 5).

Yet, this is a whole new development.
Just setting up a new compiling environment for this new processor/firmware will take a while.

Hi,
Recently I found this one at Seedstudio.
The interesting point is that is includes an STM32F205RG, 1M byte of Flash, 128k bytes of SRAM.
Now, I think it is still doing all of the Wifi/ TCP/IP stuff which presumably fully loads it.

Now, we have a bin file dedicated to the Nucleo-F411RE board.
If you can test it and report me any problem, I fix it!

Hello again,

Looking at ST.com, I found that there are 2 others boards that could accept Espruino:
NUCLEO-L152RE and NUCLEO-F303RE (apparently not yet available but described in the DM105918.pdf flyer).

However those boards won't have as much computational power as the F4x1RE boards and their pinouts/memory size, general IO functionnalities will be also fairly different.

For instance the Nucleo-F152RE has :

1. 2 DACs which is not available at all on the F4x1,
   
2. 32 Mhz only, this could be interesting in low power case
   
3. 80 Kb of SRAM which is less interesting.
   
   

So, it could become a whole set of boards.

Hi ac413,

So it worth to note that you should rebuild the .bin from the github deposit.

I changed a few lines that makes it work very correctly now for the Nucleo-401RE.

If you can test, I will push to my github the required files for the NucleoF411RE.
The flash size and pinout of those Nucleo-F4x1RE boards are exactly the same.
It is just a matter of memory sizes and frequencies of processor, so I think it won't break anything.

To build your own .bin you need to launch a terminal from ubuntu and type:

 # change to your local git cloned directory
cd ~/Espruino
 # make the expruino firmware
NUCLEOF411RE=1 make
 # flash it to the Nucleo board
cp espruino_*_nucleof411re.bin /media/your user/NUCLEO

Did the exact lines I gave you fix it? If so I'll commit them to GitHub.

Yes, the lines you gave fixed it.
I pushed those changes and some minor cleanup around there.
Since that, I think, you merged these in 1.72.

it's actually jshReset (I think?) that resets the pin state to an input if it was not defined.

Yes but those defines just swallow some init code of the serial inf structure if there are no RX and TX macros predefined in the board. However, this is now a closed issue.

it's not going to be fantastic I'm afraid!

Well, I hope to get a reasonable result with voltage regulator simply because I intend to shutdown the ESP8266 as soon as possible and power it up only when required. All of that being done by a GPIO, potentially some current limiting resistance on the CH_PD, at that point specs say 0.5 nA which is admissible. This is a web connected sensor approach, not a web controlled system. The later would require a permanent connection which is just a terrible thing to do if you expect batteries to last for months or may a year...

ESP8266

It is still unreliable/unstable as this post explains. I faced some issues of this kind after 1 or 2 weeks with Xively+Wifly and even faster with CC3000. The CC3000 just never ever reconnected to my modem/router. The Wifly did required a full reset and software update, but keeped unstable on long term. Actually, those modules do have some problems with the unreliable aspects of Wifi and Internet: they all can fail without warning or error messages and apparently this mess up the wifi/IP stacks in their inner memory.

Aside of Wifi, Xively faced unreliablity due to the internet connection itself. Some data was never received at Xively even from a Debian PC connected through ethernet.

Hi,
Bravo, it did the trick: No more scary characters in the input line after reset() or load() as shown below.

>
=undefined
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>echo(0);
=undefined
>dump();
function buttonWatcher() {
  console.log("Pressed at "+getTime());
  digitalWrite(LED1, Math.random()>0.5);
}
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both' });
=undefined
>save();
=undefined
Erasing Flash....
Programming 86016 Bytes...................................­........................................­............
Checking...
Done!
>dump();
function buttonWatcher() {
  console.log("Pressed at "+getTime());
  digitalWrite(LED1, Math.random()>0.5);
}
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both' });
=undefined
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>dump();
=undefined
>load();
=undefined
Loading from flash...
> 

I had tried to call jshResetSerial() after load or reset, however it did not do it alone. Defining the RX and TX pins does change the init sequence. That's because there are some

 [#ifdef](https://forum.espruino.com/sear­ch/?q=%23ifdef) DEFAULT_CONSOLE_TX_PIN
    inf.pinTX = DEFAULT_CONSOLE_TX_PIN;
 [#endif](https://forum.espruino.com/sear­ch/?q=%23endif)
 [#ifdef](https://forum.espruino.com/sear­ch/?q=%23ifdef) DEFAULT_CONSOLE_RX_PIN
    inf.pinRX = DEFAULT_CONSOLE_RX_PIN;
 [#endif](https://forum.espruino.com/sear­ch/?q=%23endif)

that apparently change the actual final initialisation of the serial port.
Anyway, now it is solved!

Running test on ARM boards is normally not a requirement and actually, breakpoint/watchpoint based debugging won't help much with real time problems...

Now I'll try to test more points about batteries life duration, data logging and ESP8266...

Hi @Gordon,

Well, these characters are a problem when the web IDE sends a program from the right pane to the 'Espruino'.
For instance, see line 17 below.

So far I failed to identify where, in Espruino interpreter, these characters were generated.
I guess, to achieve such a result, I have to setup a full debugger with watched variables, breakpoints, gdb, openocd 0.8.0 and st-link.

Actually, I am not far from getting gdb at work: gdb connects to openocd which connects to st-link which, in turn, connects to the Nucleo.

At that point, the Nucleo must have an already properly loaded program such as 'blink a led' in order to not have the error 'init failed'.

I get the number of hardware breakpoints and so on display from openocd.
gdb allows me to load the .elf file which I compiled with NUCLEOF401RE=1 DEBUG=1 make.

It's just a matter of setting a breakpoint at some precise line in source code and get it running in the right order. The code is started with 'continue' under gdb but never stops where I want...

That's the moment I found your page about AdvancedDebug. So I yet have to apply/transpose those directives properly.

As a secondary question, how do I launch the various tests available on a Nucleoboard? Obviously, your instructions are linux specifics.

Connected
>
=undefined
>echo(0);
<<<<<{"VERSION":"1v72","BUILD_DATE":"Nov­ 12 2014","BUILD_TIME":"16:11:50","GIT_COMMI­T":"3c4500490eb33bd2ac84a108c70a42d0bee4­a83b","BOARD":"NUCLEOF401RE","CHIP":"STM­32F401RET6","CHIP_FAMILY":"STM32F4","FLA­SH":524288,"RAM":98304,"SERIAL":"56005b0­0-0b513333-37343534","CONSOLE":"Serial2"­}>>>>>
=undefined
>
=undefined
>reset((;
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>ÿecho(0);
=undefined
Uncaught SyntaxError: Got ?[255] expected EOF
 at line 1 col 1
ÿecho(0);
 ^
>function buttonWatcher() {
:  console.log("Pressed at "+getTime());
:  digitalWrite(LED1, Math.random()>0.5);
:}
=function () { ... }
=undefined
>setWatch(buttonWatcher, BTN, {edge:"both", repeat:true, debounce: 0});
=1
>echo(1);
=undefined
> 

Good news!

So I keep having small problems with various points on the Nucleo. Working on getting rid of first chars after reset() and other details.

Congratulations: Now BTN1 and setWatch do work!!!

Connected
>
=undefined
>echo(0);
Uncaught [object Object]
 at line 1 col 9
console.log("<<"+"<<<"+JSON.stringify(pr­ocess.env)+">>>"+">>...
         ^
=undefined
>
=undefined
>reset(!;
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v71 Copyright 2014 G.Williams
>ÿecho(0);
=undefined
Uncaught SyntaxError: Got ?[255] expected EOF
 at line 1 col 1
ÿecho(0);
 ^
>function buttonWatcher() {
:  console.log("Pressed at "+getTime());
:  digitalWrite(LED1, Math.random()>0.5);
:}
=function () { ... }
=undefined
>setWatch(buttonWatcher, BTN, {edge:"both", repeat:true, debounce: 0});
=1
>echo(1);
=undefined
Pressed at 31.86450067857
Pressed at 32.05031824999
Pressed at 33.17640026190
Pressed at 33.34058927380
>dump()
function buttonWatcher() {
  console.log("Pressed at "+getTime());
  digitalWrite(LED1, Math.random()>0.5);
}
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both' });
digitalWrite(A5,1);
=undefined
>a=3
=3
>save()
=undefined
Erasing Flash....
Programming 86016 Bytes...................................­........................................­............
Checking...
Done!
>reset()
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v71 Copyright 2014 G.Williams
>dump()
=undefined
>load()
=undefined
Loading from flash...
>dump()
function buttonWatcher() {
  console.log("Pressed at "+getTime());
  digitalWrite(LED1, Math.random()>0.5);
}
var a = 3;
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both' });
digitalWrite(A5,1);
=undefined
> 

The remaining problems are now:

1. a parasitic character in the input buffer. Which creates those strange errors "Uncaught SyntaxError: Got ?[255] expected EOF"
   
2. I have to check UART6 and more details on I/O.
   
   

Just a complement about Nucleo boards:
A- port A: the ST-LINK/V2-1 is using some of its pins to debug and program as mbed needs it.

1. PA2 and PA3 are the USART2 console TX/RX.
   
2. "PA13 and PA14 share with SWD signals connected to ST-LINK/V2-1, it is not recommend to
   use them as IO pins if ST-LINK part is not cut."
   
   

B- power supplied from USB port: there is the negotiation between the host and the Nucleo that happens at boot time. If there is no agreement from the host, the Nucleo will only use 100 mA from the USB port. This happens when the Nucleo is powered from an USB power supply. The jumper JP1 determines that (manual UM1724 page 17/54). This could also be a trap when more power is required at boot time or later.

C- various default solder bridges change a lot of details around the pins potential usage.

Again thank you for supporting an "unofficial board".

Clearly, beeing battery operated does imply some compromises for the Espruino board itself as the key point is autonomy.

Sandisk specs, in my previous post, specify 2.7v to 3.6v and 100 mA at 25 MHz (200 mA at 50 MHz) which could be compatible with 3 AA rechargeable batteries for instance (3 * 1.2 v) directly connected after the voltage regulator. This could, on a battery operated mode, supply far more than enough mA for an SD card.

This is also compatible with the STM32F1 voltages and Amperes.

So the problem is that, either you slow down the writing speed to the SD card, and then it needs only 100 mA at write time, or, you are lucky to get an SD card that doesn't need so much power: No one reads or writes the spec's mA required for a particular SD card maker/model at least not until you got some failure.

Could this be a software only improvement suggestion?

I was just considering the frequency (10 s) at which data were logged.
Also, just powering out is a problem, it really is a matter to keep power on for the SD card's controller.
In case of power outage, or pulling out the power cable, a few seconds after a write you might find some symptoms like those described by Espruino_user_dk.

Of course an unreliable power supply is a problem more critical.
By the way, some SD cards do need almost 200 mA during writes or there too.
Wifi SD such as Toshiba's Flashair are also requiring 200 mAsustained during all of their connection but this is due to Wifi itself and these are not microSD.

Yes, I posted only the last results:
a- debounce doesn't change anything (0 or 100 or 200 ms). It all seems that the code is just never launched: I launched buttonWatcher() manually to check it works per itself but actually I never saw its messages when pressing the button. When set to 0 it is not displayed in the dump().
b- as a consequence I can't say if getTime keeps incrementing in that function. I removed the e parameter in order to check manually because I don't know how to feed the event time outside of the setWatch. Meanwhile getTime() does run correctly from the prompt and keeps counting from the power on moment.

Sorry, I got confused with STM32F4DISCOVERY which has 192 kB.
Still it is an interesting product.

Just a few details about sd cards and data logging:
a-All SD cards have an internal controller that, totally transparently, manages, eventually bad flash sectors, as well as strategies to speed up apparent writes to the card. It does take time to finish the writes internally. They, for instance, can be grouped by this controller.
Furthermore, there is no way for the 'host' MCU to now about the real moment the operations ended. So the worst thing to do is to cut off power, or pull out the sd card, too soon: You get randomly unreliable results because the writes were not really finished by the controller.

A delay of a few seconds, somes wrote 30 s, seems to solve it.

The Raspberry Pi forum has tons of discussions about it.
I solved it, on a Raspberry Pi, by using:
1-an overlayfs which places a ramdisk for writes only, and some sub-trees only, above the flash memory,
2-a crontab task that copied, every 4 hours, the overlayfs ramdisk to the SD card..... Which means that I accept to, eventually, loose 4 hours of data measurements.

b-Another problem is consequent of the 10 000 maximum writes on the same flash sector: It systematically happens when you append to the same file. The directory containing this file is updated at each and every write to the file.
This kills very efficiently an SD card in a few days, 8 to 10 days on my Raspberry Pi. Raspbian, ext4fs, groups writes per 5 seconds blocks. This parameter can be increased but it becomes system wide which is not safe at all.

A simple solution is to use sub-directories which are written to a limited number of times to their contained files. Indeed, this is why photo cameras are using /DCIM/xxxx/yyy.jpg tree structure for saving to the SD card.

Hi,

So, I pushed some changes to NUCLEOF401RE.py that do it for save(). There is no need to update the libraries and yes, I think that would be a lot of rewrites for the substantially little or none benefits.
Now save() resists even if you reflash Espruino interpreter itself. That's because the save() is done to the last page of the flash memory. This page is not erased when you flash the firmware.

In order to use a lower flash size F4 series you just have to follow my comments in this file.
On the other hand, flashing a NUCLEOF411RE would imply deeper changes because it has 192 Kbytes of RAM separated in 2 non adjacent memory areas.

Now I am trying to see how to have setWatch work:

>reset()
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v71 Copyright 2014 G.Williams
>ÿ
=undefined
Uncaught SyntaxError: Got ?[255] expected EOF
 at line 1 col 1
ÿ
 ^
>dump()
=undefined
>load()
=undefined
Loading from flash...
>þ
=undefined
Uncaught SyntaxError: Got ?[254] expected EOF
 at line 1 col 1
þ
 ^
>dump()
=undefined
>load()
=undefined
Loading from flash...
>dump()
function buttonWatcher() {
  console.log("Pressed");
  digitalWrite(LED1, Math.random()>0.5);
}
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both', debounce : 100 });
=undefined
>process.memory();
={ "free": 5320, "usage": 56, "total": 5376, "history": 31,
  "stackEndAddress": 536958516, "flash_start": 134217728, "flash_binary_end": 134442916, "flash_code_start": 134610944, "flash_length": 524288 }
>process.env
={
  "VERSION": "1v71",
  "BUILD_DATE": "Nov  6 2014",
  "BUILD_TIME": "09:23:40",
  "GIT_COMMIT": "f8d8135ec74c5539669ca594165876cfba03b66­f",
  "BOARD": "NUCLEOF401RE",
  "CHIP": "STM32F401RET6",
  "CHIP_FAMILY": "STM32F4",
  "FLASH": 524288, "RAM": 98304,
  "SERIAL": "56005b00-0b513333-37343534",
  "CONSOLE": "Serial2"
 }
>digitalRead(C13);
=1
>digitalRead(C13);
=0
>setWatch(buttonWatcher, BTN, {edge:"both", repeat:true, debounce: 100});
=2
>clearWatch(2);
=undefined
>clearWatch(1);
=undefined
>dump()
function buttonWatcher() {
  console.log("Pressed");
  digitalWrite(LED1, Math.random()>0.5);
}
=undefined
>buttonWatcher()
Pressed
=undefined
>buttonWatcher()
Pressed
=undefined
>buttonWatcher()
Pressed
=undefined
>buttonWatcher()
Pressed
=undefined
> save()
=undefined
Erasing Flash....
Programming 86016 Bytes...................................­........................................­............
Ãhecking...
Done!
>þ
=undefined
Uncaught SyntaxError: Got ?[254] expected EOF
 at line 1 col 1
þ
 ^
> 

I just pressed and hold down button BTN1 between last 2 digitalRead(C13)...
Apparently, the setWatch is correctly recorded when defined, dumped correctly but never launched.

This code was loaded from flash and so the answer when defining setWatch is 'undefined' but actually, it return the integer number that identifies the setWatch for the clearWatch.
As shown, buttonWatcher does its job correctly, the led changes randomly.
So both of those functions works but the interrupts are not generated.

Arduino's pin renaming is still in progress.

There is a parasitic character in the input buffer after a reset(), a save() or a load(). This is not a big issue but still preventing some reloads or reset before programming from the web IDE. Its code is 0xFE or 0xFF.

Also, I expect some difficulties with UART6 which I intend to use one day. There is FIXME somewhere is the code about it.

Have a nice day and congratulation for the Espruino Pico, you not so far away to get £50000 founding level.

Hi,

Setting up NUCLEOF401RE.py with my suggested parameters doesn't work yet:

• addresses are correct now and writing happens without any apparent glitch,
  
• errors happen after the control of the 8'th byte read, just as if something had not been waiting correctly before writing there. Could be a question of latency: 84 Mhz is far more than the 48 Mhz of Espruino board.
  
  

I still have no luck with setWatch: just no reaction to BTN1.

Having help from ST is definitely the best thing you could have.

Reading the docs shows they have been gradually expanding their variety of products and added some register's tricks incrementally too. As a result, each model of STM32F has its own particularities.
I think you should consider using the updated stm32_hal libraries as they include new functions and correct bugs every other month apparently.

So I'll try again but not so often as I expect some clean solutions on your side: You have 15 weeks to solve those things. Don't you?

Hello,

About page sizes:
There are some details from ST doc: The 2 upper pages have to be unlocked with a specific value for these sectors.
The reference manual, chapter 3.8.6 page 63/835 Flash option control register (FLASH_OPTCR), bits nWRP[7:6] shows a specific context which is somehow unclear to me.
I was wondering if the stmhal library does care about those bits or not?

Also, I tried the F4DISCOVERY values and did not had success: Apparently, the magic word address was right in the middle of the sector 6 which also contained the saved values.
I think, it is a matter of page size (tried only 16K while it probably should be 128K) and number of pages (tried 3 while it again probably should be 2).
So I have to spend more time on that point.

As a side point, you can get:
a- the size of the flash incorporated to your STM32 by peeking address 0x1FFF 7A22, value in KiloBytes, see page 829/835. This could be used to determine what special tweaks have to be done, depending upon the sector to be programmed / erased.
b- a unique id, 96-bit long, of the stm32 by peeking at address 0x1FFF 7A10

Do you use any of those already?

That's all for today...

Hello,

a- So I have tried to have save() working properly.
Obviously, my parameters in NUCLEOF401RE.py where uncoherent.
However, it is still failing at check time: I guess, there is a question of page size which is non constant on higher addresses of the flash memory on the STM32F4 series. This results from the STMF4 programming manual RM0368 Reference manual table 5 page 45/835.
It is a constant, 2K bytes, on the STM32f1 series as written in table 4 page 8/31 of PM0075 Programming manual so the code of jshSaveToFlash() is somehow simplified about this point...
I added some jsiConsolePrint here and there. Which helped me but did not changed the logic of this routine in any way.
The micropython's equivalent routine seems to use a pre computed table to determine the page size out of the flash's base address to be written. They use a STM32F4...
Changing anything in this area of the code could, potentially, be a real problem since I can't test other boards.

b- I changed the definition of BTN1 with

'BTN1' : { 'pin' : 'C13',
             'inverted' : True,
             'pinstate': 'IN_PULLUP', # to specify INPUT, PULL_UP
           }

No further investigation about it and setWatch()

c- The Arduino's connectors pins names will probably end up the an "Arduino." prefix as you suggested. mbed names are totally incompatible with Espruino conventions. Yet, those arduino's connectors pins are just straight connections to the standard Nucleo connectors: I think it could just be aliasing Arduino's names to Espruino's names...

So far nothing else, I am focused on save() problem.
This is an important function to get an Espruino firmware useful on the Nucleo.

Thank you!
I confirm that digitalRead(BTN1) answers 1 with button not pressed.
I will try the new values for memory and sizes by tomorrow.

Pin names are a limited problem, I just choosed to use the Espruino's naming convention even for the Arduino's shield connections. This is just an arbitrary choice because finally it complies with the other ST boards and allows for a greater compatibility with Espruino itself. Using the Arduino's pins names would just create complex situations.

This is yet to be definitely decided anyway. Any suggestion such as yours will be welcomed: it has to be simple to remember.

Did my very very first git pull worked correctly?
Discovering Travis is just the next step about continuous integration.

Congratulation for the Espruino Pico founding, I guess I am one of the super early birds.