Today I wanted to test some serial stuff, comparable to the second example on this page.
Howerver, while mixing up some wires and pin numbers, I spent quite some time looking at numerous code variations, all resulting in a binary showing some cheerful fault pattern on the mBuino.
LEDs 1 to 4 were blinking, alternating between LEDs 1 & 4 and LEDs 2 & 3.
When trying to find out what this pattern meant, I couldn’t find it anywhere.
Is there any documentation on mBuino error codes, or is this simply the only way mBuino signals various different kind of faults?
I could be mistaken, but I don’t think there’s any built-in code to blink the LEDs as error codes.
The default firmware does blink the onboard LEDs in a pattern, but it should blink them all.
Can you share the code you’re using that shows the pattern you mention? You can use the code button above the editor window (the one with the 1s and 0s) to format your code.
Hi @ devhammer, thank you for the swift response. I just reproduced the LED 1-4 blinking pattern using this code (somewhat modified version of the second example here).
Just tested a bit more. The blinking doesn’t occur when powered using a usb-powerpack; only when using my windows PC, so it could be related to the driver in combination with the USBDevice library. I’m now trying to make the minimal code version that shows the blinking.
Note: this code is knowingly messed up.
Import the USBDevice library to compile and use at your own risk.
#include "mbed.h"
#include "USBSerial.h"
USBSerial pc; // tx, rx
Serial device(P0_9, P0_10); // tx, rx // any other pins than P0_19, P_018 cause blinking
int main() {
/* not needed to reproduce blinking
while(1) {
if(pc.readable()) {
device.putc(pc.getc());
}
if(device.readable()) {
pc.putc(device.getc());
}
}
*/
}
@ maxint - I’m not able to reproduce the symptoms you describe with this code, regardless of whether I include the loop in main or not.
When I deploy the compiled code and reset the board, I get the USB connect sound, and all of the LEDs light dimly, which in my experience is an indication that something is wrong with the code (under normal use the LEDs should light up dimly when in loader mode, but they should be off when the board is running normally, unless your code is turning them on).
Sorry that I can’t help more, but I’m just getting started with mBuino myself, and I’m a newb at C++.
Hopefully one of the other folks with more experience will chime in…
@ maxint - OK. I was able to reproduce the pattern you’re seeing, but only by using the following code (note that I commented out the USBSerial declaration):
#include "mbed.h"
#include "USBSerial.h"
//USBSerial pc; // tx, rx
Serial device(P0_9, P0_10); // tx, rx // any other pins than P0_19, P_018 cause blinking
int main()
{
/* not needed to reproduce blinking
while(1) {
if(pc.readable()) {
device.putc(pc.getc());
}
if(device.readable()) {
pc.putc(device.getc());
}
}
*/
}
Now that I’m seeing it, it does look like some kind of error indication.
I also commented out the line of code that imports the USBSerial library, and the blinking symptom remains, so we can eliminate that as the source of the issue.
There’s some interesting stuff up on the mBed site for Serial PC comms, but I saw some info that suggests the required driver may not work on Windows 8 (I’m on 8.1, and could not get the driver to install…kept telling me that no mbed microcontrollers were found). Then again, other posts indicate that folks have successfully installed the driver, so who knows. Here’s some info, anyway, in case it’s helpful.
So if you’re trying to initialize with pins 09 and 10, that’s probably why it’s failing.
I combined code that initializes serial on pins 19 and 18 with the default blink program, and it runs normally.
Unfortunately, I can’t easily test serial communication at the moment, since I can’t get the serial driver to install, but I’m guessing if you stick with pins 19 and 18, you should be OK.
But for serial communication to the PC, you may need to use USBTX and USBRX values, which according to the docs connect to the PC via USB, rather than the pins.
@ devhammer and @ architect: Thank you for your time. Much appreciated!
@ devhammer: Good you could find a way to reproduce. It seems indeed that it has to do with incorrect usage of pins. As stated in the code-comment, I also noticed that pins 19 and 18 did work appropriately. Coming from an Arduino environment I presumed that using other pins than the ones in the schema could also function (as software-serial).
However, I was a bit surprised seeing the blinking pattern, without finding any documentation on it.
BTW: I can also confirm that when using the correct pins, I do have a successful connection. I then get valid results in the serial monitor I use for debugging (Putty). This was merely a side effect of me testing something else. However, if anyone can tell a bit more about this blinking error signal or point me to documentation listing this pattern, I’d appreciate it…
(FYI: my testing involves an ESP8266 WiFi module on mBuino. These modules are quite interesting as they are very cheap and seemingly easy to apply using a simple serial interface. Unfortunately documentation and support for these modules is still a bit lacking, but the community is growing and developing many cool applications.
Stand-alone using an USB-to-serial plug my module passed all basic tests. With mBuino most basic commands succeed, but larger data-results don’t show all data, which I still need to debug. I suspect that to be some buffering issue…)
You may be right that the pattern is an error indicator. I just find it odd that I’ve never seen it before, but as I said, I’m still new to the mBuino platform.
@ AndyA - Thanks for sharing that…I figured someone around here would know.
Would be interesting to find out if stdout is surfaced somewhere in mBuino…didn’t even know that existed.
Regarding the error pattern, would that occur with any invalid config? For example, if you tried to configure PWM on a non-PWM pin, would that also show the same pattern?
The rather inaccurate naming is because on most mbeds stdin/out and stderr default to the USB serial port which to most mbeds looks like a normal serial port and doesn’t require any USB software on the application side to use.
Hello @ AndyA. Thank you for this information. Being a newbie on the mbed platform it’s nice to have experienced people such as you around.
Do I understand correctly that pins 18 and 19 are defined as USB pins for legacy reasons and that they are not connected nor related to the actual USB port on mBuino?
In my testing I already encountered the definitions of USBTX and USBRX. By successfully using the micro-usb for debugging and pins 19 and 18 for the serial connection to the ESP8266 I already came to a similar conclusion, but since not all output was correctly copied to the debug-usb, I was doubting if they were truly unrelated.
And another question: on Arduino there are classes allowing me to use a self selected set of pins as software serial. As they let the MCU do the bit-banging, these operate at a slower speed, but still come in handy. Do you know of such classes on the mbed platform?
Correct, they are simply aliases for P0_18 and P0_19.
USBTX and USBRX are historically the pins for UART that is connected to an external USB/Serial converter. When no such converter exists they are simply the first UART.
Nitpick - they are port 0 bits 18 and 19 not pins 18 and 19. That is their CPU memory locations and has no relation to their physical pin numbers on the device, physically they are pins 31 and 32 in the package used on the mbuino. But since the silkscreen on the board indicates the logical pin IDs rather than the physical pin number this whole nitpick is fairly pointless.
One thing to watch out for is that some libraries will output status or errors to stdout or stderr. If you are using that port for communicating to another device this could cause a problem. Once of the the downsides to community generated libraries is a lack of consistency in this sort of thing.
If this is a problem there are two workarounds that you can use:
modifiy the library to remove the output
use the mbed-src library rather than the mbed one and then in
targets/hal/TARGET_NXP/TARGET_LPC11UXX/TARGET_OC_MBUINO/device.h
change #define DEVICE_STDIO_MESSAGES 1
to being 0
You can also disable the error LED blink there if you want to.
Odd. Shouldn’t be related.
I’ve never used one, I thought I had seen one but I can’t find it anything now, the best I can dig up is incomplete and hasn’t been touched for 2 years.
The mbed API is all fairly generic high level stuff since it needs to run on a range of different controllers running at different speeds made by different manufacturers. Unfortunately that makes getting the timings required for a software UART correct somewhat harder on mbed than on arduino which is a little more consistent. Since most of the mbed CPUs have 3 or 4 UARTS there isn’t much incentive to put the effort in to add more.
Yes. It’s a generic fatal error during hardware setup error pattern.
You could in theory get it while running a program if you dynamically create the serial port (or PWM etc…) object but normally you’re only going to get it on startup.
@ AndyA - thanks for all the information. I’m afraid I’ll need to spend more time debugging to find the missing characters in Serial data of larger sizes. Perhaps it’s timing related. Hopefully those potential error messages on stderr don’t occur nor mess up the data-exchange to the ESP. Lacking software UART or additional exposed serial ports on mBuino doesn’t leave me with many alternatives, so thank you for your tips on how to change the libraries.
