F401 Nucleo Espruino Question

Posted on
Page
of 2
/ 2
Next
  • Playing with the F401 w/ Espruino while waiting for my Pico's to arrive :)

    I barely know enough yet to even type this question, but perhaps someone can help...

    I am fooling around with beginner examples from Espruino.com, and I typed in the example

    var interval = setInterval(OnSec, 1000);
    

    where OnSec() maintained a "time" object with seconds, hours, days, etc. This worked just fine, and I was embellishing it when I noticed that it seemed to be running really slowly. So I added a console.log(getTime()) that got executed every 10 seconds and I noticed it took approximately 50-60 seconds between logs.

    So, what am I doing wrong? My first guess, and bear with my noobidity please, is that something in the .bin is still set at 16MHz instead of 84MHz, or perhaps 16MHz is the default for the F401 Nucleo and I should have done something to make it run at its faster setting.

    Thanks in advance!

    Edit: Just noticed that the Espruino runs at 74MHz, so there goes that noob guess.

  • To my knowledge, the board has a user button - does it? You can use it with a bit of code and a watch w/ second hand to (roughly) figure out what - it at all - clocking has an impact.

    Set a repeating watch on the button with a callback that stores the time in an array. Then you take some times like taking lap times: press the button, watch your watch for 10 seconds, press the button again, an do that several times.

    After that, list the array in the console window and do some math...

    Copy following code into the edit area in the IDE and upload it to the board.

    var ts = [];
    setWatch(function(e){ts.push(e.time);},B­TN,{repeat:true,edge:"falling",debounce:­10});
    

    For the explanation of the code look take a look at:http://www.espruino.com/Reference#l__glo­bal_setWatch

    I kept the function as terse as possible to have minimal impact on time.

    For looking at the times captured enter the following in your console:

    console.log(ts);
    

    If there are not too many times in the array, it will list them all. Otherwise, use enter the following to get them all, each on a single line:

    ts.forEach(function(t){ console.log(t); });
    

    For more luxury or convenient math, add this snipped to the code initial code which you upload to the board.

    displayResults() {
    var i, t0 = 0, cnt = 0, sum = 0;
    ts.forEach(function(t){ 
      if (cnt > 0) {
        i = t - t0;
       sum += i;
        console.log(t, i); 
      } 
      t0 = t; cnt++; 
     });
     if (cnt > 0) {
       console.log("average of ", cnt, " x-second measurements: ", i / cnt);
     } 
    

    To show the results, enter displayResults() in the console.

    If you pressed the button 11 times - every ten seconds, you will get 10 values you can average... and if you do not get a value close to 10 (seconds), then you know that the clock has an impact. If there is an impact, you may calculate a correction coefficient sufficiently accurate... and if you want it more accurate, you can take it minute by minute, or even hour by hour and do the math... with error calculation (this will give you a calibrated correction coefficient).

    To repeat the process, just upload the code again, or enter ts = [] in the console to empty the time collector array.

    Btw, your numbers look odd to me, because they should have some relation to the clock frequency... but I'm sure @Gordon has a much better explanation than my empirical approach is based on.

  • @allObjects, thanks for the reply!
    I am going to read/try your suggestions right now, but I just re-read my initial comment and I wanted to clarify that whenever console.log(getTime()) printed, it was very accurately 10 seconds since the last log, however, by my stopwatch it was more like 50-60 seconds.
    Thanks again!

  • Edit: Multiple edits, I apologize if anyone read this post while I kept fixing it!

    OK, first simple test...here is the code I used:

    setWatch(function(e) {  console.log(getTime());
      console.log(e.time - e.lastTime); }, BTN, { repeat:true, edge:'falling', debounce:10});
    

    I pressed/released the button, waited 60 seconds wall time, then pressed/released the button:

    18209.36011569047
    3.37781286905 // ignore this
    18220.76388179761
    11.38100977380
    

    So 60 seconds wall time was approximately 11.4 seconds "computer" time, about a 5 1/4 times slowdown.
    Any ideas?

    BTW: I appreciate your code, and I get it; it helps me to see examples right now to absorb them. I'm just not sure I need more than the setWatch() you helped me set up to know that something is up.

  • @Manxome - thanks, I'll take a look at it (I'm a bit busy this week though!).

    The F401 binary is very new, and while it uses the same processor as the Pico it keeps the time a bit differently. It could well be that something has got set up wrong in the processor, and so the timings are all off.

  • Thanks @Gordon! Please note that I modified that last post several times, so what you read probably isn't what I ended up with, but if there is a timing issue, perhaps you know enough to find it already :)

  • 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
    > 
    
  • the 5-1/4 vs. the calculated 4-1/2 (72 / 16) value can make sense, because the timer internally fires events to update the time more often and base on the clock. The cycles used to handle the timer event is usually taken into account and is with the internal timer/interval value for sure not linear with the time itself.

  • On the Espruino board (and the Pico) there's the RTC, but also another software timer based on SysTick that 'follows' the RTC and allows the board to make very accurate time measurements.

    On other boards (like the Nucleo) that doesn't happen. Instead SysTick is used directly, which means that you're totally dependent on the speed that the processor is running at.

  • Thanks very much for the replies all!
    I am getting a better feel for these forums now and I better appreciate that I am working on an "Unofficially supported board" and that support for these Nucleo boards will of necessity be a lower priority and any help that some (especially Gordon) provides, 'pulls' help from
    Espruino/Pico support/issues. I have ordered a bunch of Pico boards and am rather impatient so wanted to get playing with Espruino JS ahead of their arrival.
    OK, onward!

    Are you using an NucleoF401RE or an NucleoF411RE?

    I have both, but have only been playing on the F401 so far

    Have you updated your firmware from st.com?

    Yes, basically followed the instructions on the F401 page.

    I decided to start from scratch. I downloaded fresh copy of F401 firmware from ST and did the ST-Link Upgrade to V2.J23.M6 (again) just in case.
    I downloaded Espruino 1v71 (again) and copied espruino_1v71_nucleof401re.bin to the Nucleo.
    I pulled the USB cable and then re-inserted it, and attached to it with the Chrome Web App.
    Here is my session:

    > // I will do a reset() here, sometimes things get overwritten with strange characters...
    =undefined
    ª¹¥¹5
     _____                 _
    |   __|___ ___ ___ _ _|_|___ ___
    |   __|_ -| . |  _| | | |   | . |
    |_____|___|  _|_| |___|_|_|_|___|
              |_| http://espruino.com
     1v71 Copyright 2014 G.Williams
    > // yes, the reset() was overwritten. Now I will do the setWatch() and save() it.
    =undefined
    Uncaught SyntaxError: Got ?[128] expected EOF
     at line 1 col 1
     // yes, the reset() was overwritten. Now I will do the set...
     ^
    >setWatch(function (e) {  console.log(getTime()); console.log(e.time - e.lastTime); },
    :  "C13", { repeat:true, edge:'falling', debounce : 10 });
    =1
    >save();
    =undefined
    Erasing Flash....
    Programming 86016 Bytes...................................­........................................­............
    Checking...)Done!
    > // now i will do a 10-second test using the button...
    =undefined
    Uncaught SyntaxError: Got ?[128] expected EOF
     at line 1 col 1
     // now i will do a 10-second test using the button...
     ^
    176.18122399999
    NaN
    178.09457523809
    1.88026453571
    > // now I will do a 60-second test...
    =undefined
    200.72823180952
    5.64045157142 // edit: ignore this number. I screwed up a 60-second test prior, phonecall.
    212.17027785714
    11.40336201190
    >
    

    Those comments I typed in as I went. You will notice I get 'funny stuff' going on, perhaps this is a clue that I haven't a clue and/or I have bad hardware/firmware/something.

    But once again, you can see that both tests took about 5.25 longer than "computer" time would indicate.

    I don't know (yet) how to ask the Nucleo what clock speed it is running at.

  • Here is a discussion of F401 clock speeds out of the box.
    If you take a look here, you can see two crystals (X2 & X3) to the left of the STM32F401 chip.
    If you take a look here, one of those crystals is missing.
    My F401 Nucleo board does NOT have either of those crystals.
    My F411 Nucleo board only has the upper black (X2) crystal.
    84MHz divided by 5.25 is 16MHz. Perhaps new boards are crippled? I am a programmer, not a hardware guy, so if I am completely out in left field...be gentle :)

  • My interpretation is that their thinking was "Oh, we'll leave out the crystal so the person developing with this can run it at whatever speed they want" - but this means you need a crystal to make it run at 84 x_x

    I think it's the black one, X2, that's used to set the clock speed of the MCU, but I'm not certain.

  • From more research I am pretty certain that F401 Nucleo ships at 16MHz.
    Discussion here about boosting it to 84MHz using mbed. Don't know how hard it would be to do this at initialization in the Espruino code...

    @DrAzzy, it sounds like the board can run at 84MHz without the crystals, but I am far from a hardware guy...

  • Yup, that explains it - It sounds like this is something that the Espruino firmware ought to be doing, but isn't.

  • Hello @Manxome, @Gordon,

    The speed problem of the Nucleo is also described here and is well worth reading.
    Interestingly, Kenji Arai provides a test software that shows most details about it and suggests some solutions that could work, or not.

    If you have a F401 which is what the UM1724 manual calls a "MB1136 C-01" then it doesn't use HSE (High Speed External clock) and that the main point.
    Mine is a "MB1136 C-02" which uses the ST-LINK MCO as clock input as stated in UM1724 page 22/56. Furthermore it is not in the configuration defined by UM1724 for HSE to use MCO from ST-LINK: SB54 is ON while the manual states it should be OFF.
    I am lucky to have a working hardware / software combination but the previous subject shows that it is quite unprobable.....

    From what I understand so far, it will need more than just software debugging/corrections to make it work in any or every case.
    Integrating the 'easy solution' is just a beginning.

  • @Manxome so you're saying that over 60 seconds it's out by 5.25? I guess mine may do the same as I only tested that it was roughly correct.

    Interestingly my F401 board has just the black crystal (which is a 32k clock crystal - so not the high speed oscillator).

    @asez73 it looks like probably the best method right now is to just use the HSI, which will work on all boards - and which we know the speed of.

    I don't think there will be a huge problem - I think HSE is only really used because of USB.

  • And I thought software was complicated, sigh...

    My F401 Nucleo has a sticker on the back that says "MB1136 C-01" and has only the X1 (8MHz) crystal.
    My F411 Nucleo says "C-02 and has X1 & X2 Crystals.
    I understand that the X1 crystal actually belongs to the ST-Link portion of the board but could theoretically be used by the STM32F4x1 if configured properly.

    What does "MCO" stand for?
    @asez73, your F401 appears to run at 84MHz in your testing, yes?

    Not oddly, I am still somewhat confused. Are these the 2 possibilities?

    1. C-01 board, no external crystals used, no external crystals present except for X1 (8MHz) on ST-Link board, uses internal clock, runs out of the box at 16MHz, can be configured for 84MHz, but not as accurate as if it had/used an external crystal, and actual speed can also vary with temperature.
    2. C-02 board, has X1 and X2, uses X2 (32.768KHz), runs at 84MHz out of the box, very accurate within the (fairly broad) temperature range.

    I suppose adding X3 (and caps etc.) would allow you to break off the ST-Link if desired and still use an external (8MHz) crystal.

    If I added X2 and the caps and moved around the resistors, my F401 Nucleo would boot up at 84MHz using external X2 crystal, yes? No software initialization needed.

  • @Gordon yes, my 60-second test was off by a factor of 84/16, ie, 5.25.

    Interestingly my F401 board has just the black crystal (which is a 32k
    clock crystal - so not the high speed oscillator).

    The C-01 version of the motherboard has neither X2 or X3, the C-02 version has X2. You got yours directly from STM, so they sent you the latest version I guess. I got mine from Mouser just last week and it was C-01 so I guess they dumped old stock on me :(

  • I am am expecting one from Mouser today. I was looking forward to getting it but not any more:(

    I'd other things to get (including a wiz550io) and just ordered it to get above £50 for free shipping so no big deal anyway.

    Lesson learnt - stick to the official boards which just work out of the box!!

  • @Gordon,
    Well the USB is actually not used by the F401 side of the board.
    The F401 uses a serial link, USART2, to the detachable ST-LINK/V2-1 debugger/programmer.
    The later is actually doing all of the USB enumeration and console output on the USB port so as to be an mbed platform...
    The HSE, ironically, is not used by the "MB1136 C-01", which, I guess, explains why they run slowly.
    This describes what happens at boot time, search for HSI.
    I have to admit being reluctant to get this down with clocks on such a board.
    You will understand it much better than I, as well as the example joined to speed up the NucleoF401RE without HSE.

    @Manxome,
    Yes it runs at 84 Mhz: didn't check that with an oscilloscope but it keeps time acurately.
    If you modify your Nucleo-F401RE to be alike an "MB1136 C-02", I think you should get the expected result: no software to change, just runs as is at 84 Mhz. The differences are explained in the DM00105823.pdf aka UM1724.pdf. Apparently mine is "MB1136 C-02" but it has a slight difference with the manual: SB54 is ON.

  • @asez73, thanks for the info, very helpful :)

    @DaveNI, please let us know which version (C-01 or C-02) of the Nucleo board you get from Mouser, thanks!

  • I actually got mine from Farnell. No freebies for me :)

    I understand about USB. I think given the right config you should be able to get pretty fast off of the internal RC oscillator. I'll have to see what can be done.

  • I missed the FedEx delivery this afternoon but have just picked up my delivery from the depot - the first thing I did was look at the F401 version - like you it's the C-01. Hopefully we can make use of them!

    I am also from a software background and have little hardware experience. I have been using one of Gordon's boards for a few weeks and have really enjoyed it.

    It's a long wait until April for your picos - maybe you should get an official board - if you do just make sure it is a 1v4. I ended up with a 1v3 from digital means but it's fine - very robust & has endured my clumsy soldering!

  • @DaveNI, I really think the F4x1's are great boards, they will simply force us to learn more :)
    I ordered 10 Picos! No money left for an Espruino board LOL.
    BTW, I had serious soldering deficit skills until I found EEVBLOG. Dave is awesome and sent me down the right roads for tools, skillz, and attitude, check him out.

  • What the heck???

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

F401 Nucleo Espruino Question

Posted by Avatar for Manxome @Manxome

Actions