Nucleo F401/411 nightly builds

Since I recently found myself with a number of nucleo boards, I needed to have a source of firmware for them, since the official github builds are only done for the official builds.

I've added them to my nightly build scripts that I use for bigram builds, and these builds are now available from:

http://drazzy.com/e/espruino/NucleoF401
http://drazzy.com/e/espruino/NucleoF411

These are built from github repo with no modifications or fixes.

setWatch() doesn't work.

Neither does flow control - you need to use throttle send.

Thanks - I guess it's hard to see, but does flow control work with other terminal apps? I think XON/XOFF should be enabled by default now.

As far as I remember, Chrome doesn't provide support for XON/XOFF (software) flow control - but another program which does may work better

I'll try to check that - it seems to be pretty easy to reproduce - you can do it by pasting into the left side of the screen. I'll see if I can trigger it with another console.

It seems like more than like 400-500 characters at once is enough to break it. I think the problem may be related to how they connect to the F401 chip - instead of using builtin USB, it's communicating over serial2, and the ST Link chip is providing a USB <-> serial converter...

You could check E.getErrorFlags() to see if Espruino thought it had trouble.

It could be ST's side, but it's always been the case that if you send 123[enter] then Espruino has to echo back 123, then line feed, then =123. If you just did that over and over as fast as you could then because Espruino is sending more than it is receiving, it'll run out of buffer space.

echo(0) should basically fix that, but if you paste data in then there may be a similar problem.

I connected using the Arduino Serial Monitor (hey, I barely had any time last night), and in that, I was able to copy/paste the entire command for adding the AT24 module to the cache (copied from command history after sending using the IDE and throttling). I'll hopefully have a chance to test tonight in a bit more detail.

I was only pasting because when I tried to send with the IDE "Send to Espruino", all i could see was echo(0); - it never went back to idle. I was never able to get it to accept echo(1) at that point. I thought I'd been hitting ctrl+c before typing echo(1); into the void, but I was not ever able to get it to communicate again without disconnecting and reconnecting (at which point there was no sign of anything). So the copy-paste was a step to try to see what was going on - and when I did that, I found that things were getting cut off.

E.getErrorFlags() returns an empty array.

Hmm, that is strange. If E.getErrorFlags() is returning an empty array then it could well be either the Nucleo's interface itself or the computer. I did find that the Web IDE has issues when terminal apps like Minicom didn't. I wonder whether their Serial implementation chucks away data if it hasn't been able to send it for a while?

That could be.

F411 wiznet build should work now. As in, the file should be generated. Whether it works or not is a different matter.

Not sure what changed, but setWatch() works now, on both 401 and 411! Thanks Gordon!

Also, before flashing, do reset(); save(); to clean out the stored program - after flashing latest, I needed to reset to get builtin functionality to work.

Huzzah! hurray for working setwatch!

Hm, it can't seem to use H0 or H1. (no external oscilator is connected)

setWatch() works now

Were you using it in BTN1? I think there may have been some issues with the pullup.

can't seem to use H0 or H1

Any error messages, or it just doesn't work?

Just doesn't work. I wonder if they're being used for something by the system. They seem to have 1.6v on them when I measured them - maybe there's a clock signal there...

Before I was getting errors saying it couldn't set watch on the pin, did I have watch on another pin of same number, no matter what pin.

Strange... maybe it was an initialisation issue, although I don't think I've tweaked anything around there :(

My guess is that it's still trying to use the oscillator. It's probably this helpful line that should maybe be:

RCC->CR &= ~((uint32_t)RCC_CR_HSEON); // disable HSE