Using TTL Level Signals/Communication on wCK Bus & BT So
by l3v3rz
Tue Feb 07, 2012 8:08 pm
This was going ok 
, I had the board auto connecting to my local wifi hub. I'd edited the files in /etc/config to get things working and the only issue I had was that the routing table wasn't quite right on boot up - if I manually edited it to remove some default routes being auto added it worked. I'd simplified the devices as well to just eth0, wlan0 and lo (dropping all the bridging lans).
But then on a power recycle the serial just stopped working. The USB converter flashes when I send a character but I'm getting no output? The board appears to be running - green light comes on at reboot etc just no serial? Not sure if its bricked in some way or hardware failure -???
, I had the board auto connecting to my local wifi hub. I'd edited the files in /etc/config to get things working and the only issue I had was that the routing table wasn't quite right on boot up - if I manually edited it to remove some default routes being auto added it worked. I'd simplified the devices as well to just eth0, wlan0 and lo (dropping all the bridging lans).
But then on a power recycle the serial just stopped working. The USB converter flashes when I send a character but I'm getting no output? The board appears to be running - green light comes on at reboot etc just no serial? Not sure if its bricked in some way or hardware failure -???
by PedroR
Wed Feb 08, 2012 11:19 am
Hi l3v3rz
From our experience it's a bit hard to brick these boards although we've had a couple that locked up when getting to the bootloader.
From what we've seen, you should always be able to see something coming out of the serial port of the Omnima when you turn it on (it may later crash but it typically doesn't go down without spitting out some characters first).
The boards that we managed to "kill" always showed something when they booted but locked up when getting to the bootloader.
Therefore my best bet would be to check the USB2Serial adapter and also the cables. (not sure which USB2Serial you are using though; to be honest we don't like the Cable from Omnima and prefer the generic USB2TTL from Sparkfun based on FTDI)
You also need to make sure to connect GND (<strike>we've done some experiments with connections between omnima and other devices that worked fine without gnd connected but when using a USb2Serial we seem to always need GND</strike> Edit: I stand corrected. you always need to connect GND. What happens is that sometimes you're using a common ground without noticing it; a typical scenario is a computer that is grounded by the wall plug and a peripheral (ie robot) that is also ground by the PSU connected to the wall socket (hence common ground). ).
Another fault we've seen was with jumper cables that "seem" to be ok upon visual inspection but they were actually faulty (replacing them solved the issue).
Finally, I would check the COM port settings... I know this is a basic one but just as reminder, on boot it should be set to 57600, 8 data bits, no parity1 stop bit (8N1).
This should let you "see" the bootloading process.
Let us know how it goes
Regards
Pedro
From our experience it's a bit hard to brick these boards although we've had a couple that locked up when getting to the bootloader.
From what we've seen, you should always be able to see something coming out of the serial port of the Omnima when you turn it on (it may later crash but it typically doesn't go down without spitting out some characters first).
The boards that we managed to "kill" always showed something when they booted but locked up when getting to the bootloader.
Therefore my best bet would be to check the USB2Serial adapter and also the cables. (not sure which USB2Serial you are using though; to be honest we don't like the Cable from Omnima and prefer the generic USB2TTL from Sparkfun based on FTDI)
You also need to make sure to connect GND (<strike>we've done some experiments with connections between omnima and other devices that worked fine without gnd connected but when using a USb2Serial we seem to always need GND</strike> Edit: I stand corrected. you always need to connect GND. What happens is that sometimes you're using a common ground without noticing it; a typical scenario is a computer that is grounded by the wall plug and a peripheral (ie robot) that is also ground by the PSU connected to the wall socket (hence common ground). ).
Another fault we've seen was with jumper cables that "seem" to be ok upon visual inspection but they were actually faulty (replacing them solved the issue).
Finally, I would check the COM port settings... I know this is a basic one but just as reminder, on boot it should be set to 57600, 8 data bits, no parity1 stop bit (8N1).
This should let you "see" the bootloading process.
Let us know how it goes
Regards
Pedro