|
|
|
Forum Member
 
Group: Forum Members
Last Login: Saturday, August 14, 2010 12:06 PM
Posts: 44,
Visits: 70
|
|
Hello,
Had my Traxster working great with RoboRealm and a TrendNET TV-IP422W wireless IP camera. I am using a Serializer V2.0 board. Both the Serializer WL 2.0 board and the Bluetooth module were set to 57,600 baud.
I hadn't used the robot in a couple of days and had guests over today that wanted to see the robot. Nothing I could do would get RoboRealm to communicate with the robot, so I decided to make sure my Bluetooth module (A7eng eb301) was working--it was just fine--I was able to open the Bluetooth as a COM port but I still wasn't taking with the Serializer board.
I disconnected the Bluetooth serial wires and connected an FTDI USB (TTL) cable to the appropriate pins (note that I have always used TTL serial). When I power-up the Serializer WL 2.0 board, I noticed that I was getting garbage on the screen at 57,600 baud, so I went back to the default baud rate of 19,200. Sure enough, I'm getting a message when I power up that ways "Wait" followed by "Load."
I'm running Windows 7 x64 Professional and do not have HyperTerminal. I do have PuTTY and a few other command-line type options. I've tried the following methods to upload the 1.5.2 firmware to the Serializer:
1. Used ImageCraft's ICC12 V7 IDE with their terminal mode--I can send the .hex file with this IDE. After the Load prompt, I get a frozen screen (expecting messages during the firmware update), and when I power cycle the board, I see the Wait->Load prompt again--sometimes I see a "Chksum" error.
2. I tried the same firmware update using Axiom's IDE (for the 9SHC12 device) with similar results. The nice thing about the Axiom IDE here is it allows me to control pacing and to also wait between lines. Increasing the values in the pacing field would pop up a "Chksum" error after the first couple of lines from the firmware upload.
3. I can't figure out how to send a file using PuTTY--I can control the serial port, etc., and that's about it. This is useful for a working connection, but doesn't have the good old HyperTerminal capabilities.
4. Opened up a command prompt and tried various versions of "copy serializer.hex com2:" or "cat serializer.hex >com2:" with similar results as above. I even used the "mode" command tried setting the handshaking to Xon/Xoff and toggled between 8/7-bit transmission. All this is being done at the Serializer's default baud rate of 19200.
Does anyone have any idea on how I can get the firmware loaded back to the Serializer WL 2.0 board using an FTDI USB-TTL serial cable (purchased from A7 Engineering when I bought my eb301 Bluetooth module--it has the same pinouts as the bottom (odd) row of their header--and it's the 5V version (quite useful, really). I read through the firmware upgrade directions on the Robotics Connection website and tried to mimic what hyper terminal would do.
My power source is a 12V SLA battery, since the TrendNET TV-IP422W wireless camera requires a 12V supply. I have nothing connected to the Serializer board such as servos, etc., besides the Bluetooth module (connected separately--not using the module that RC.com sells).
Thanks much,
--Scott Thompson
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: Monday, October 31, 2011 9:18 PM
Posts: 640,
Visits: 819
|
|
| Hi Scott, I've never been able to use PuTTY to upgrade the Serializer v2.0 firmware (because it's not easy to configure the inter-character and line delays, which that bootloader required to properly load)...That's why for Serializer v3.0 we replaced the old bootloader with TinyBootloader, and we use TinyBld to upload the firmware. It's much faster, works every time, and makes it an overall better product. That being said, I'll be glad to reflash the firmware for you. We use CCS ICD-U64 to flash the bootloader and firmware combined. Actually, I can send you the combined hex file, and you can try flashing that. If that doesn't work, then we'll replace it w/ a 3.0 board. This will probably work fine...but... We had problems with about 4-5 of the last batch of 150 of the v2.0 boards which had bad voltage regulators. See this post for more info on how the vregs cause the firmware to become corrupted. I'm sorry that happended to you...I'm pretty pissed that those vregs have caused problems for customers. Let me know how you'd like to proceed. Best Regards!
Jason Summerour
President,
Summerour Robotics Corporation
www.roboticsconnection.com
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: Saturday, August 14, 2010 12:06 PM
Posts: 44,
Visits: 70
|
|
Jason,
Thanks for the reply. I impulsively ordered a Serializer 3.0 board, then took a nap. I remembered that we have one computer that still has Windows XP and just found the necessary HyperTerminal files and was able to update the firmware on my V2.0 board to 1.5.2.
Do you recall which of the two voltage regulators was the culprit (the primary or the secondary that has the jumpers to the servos)? Nothing is getting hot (I'm not running anything besides the Bluetooth adapter of the 5V supply), but I can certainly try a heatsink (can you include a spare in my Serializer 3.0 order?).
I'll hope for now that this won't happen again; otherwise, I'll let you know how we can possibly come to a resolution.
Thanks for the insight--I'll keep my cables handy in case I need to program this again in the field.
BTW, as soon as I updated the firmware, I noticed that it retained my prior baud rate (must be in EEPROM), so all my parameters are still a 'go'. What a strange issue...
--Scott Thompson
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: Monday, October 31, 2011 9:18 PM
Posts: 640,
Visits: 819
|
|
| Scott, Oh, okay.  Thank you for the business! It was the main voltage regulator that was the culprit. We actually put a heat sink from the factory on the Serializer v3.0 boards. LoL So, you shouldn't have to worry about it. Yeah, if it happens again, we'll do whatever to make it right. I don't want unhappy customers. Yeah, that's odd w/ regards to the eeprom settings...might have been a stuck bit. The first time the Serializer boots after a flash, it configures the EEPROM w/ the factory settings. It looks at a bit in EEPROM to see if it's a fresh flash. So, I'm guessing the bit that it looks at to see if it's a fresh flash wasn't set, thus causing it to read the eeprom settings, instead of overwriting them. Dunno. Best Regards!
Jason Summerour
President,
Summerour Robotics Corporation
www.roboticsconnection.com
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: Saturday, August 14, 2010 12:06 PM
Posts: 44,
Visits: 70
|
|
Jason,
So that I understand the mechanism that may have corrupted the eeprom or flash (firmware) w.r.t. the voltage regulator, is the problem likely an overvoltage condition or more like an undervoltage problem (e.g., when powering off but running a program, due to a rogue robot running across the room ready to crash into something!)--I haven't looked at the schematic or board--is there a MCU voltage supervisory subsystem on the voltage regulator that resets the MCU in case of a brownout?
BTW: any news on the firmware modifications to implement the watchdog/heartbeat feature so that the 'bot can reset itself in case of a communications loss or the like (e.g., periodically sensing an incoming CLWDT command, monitoring the toggling of a digital I/O pin, etc.)? I seem to recall this was something that was considered last year.
Happy holidays to you and your crew,
--Scott Thompson
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: Monday, October 31, 2011 9:18 PM
Posts: 640,
Visits: 819
|
|
| Scott, We think it was more of an undervoltage condition. Ringo can answer about the voltage supervisory subsystem...Don't know if he added one or not. We've added the code for the heartbeat, and need to do final testing. I'm currently trying to get the following done: - A major product released (Jan 4th)
- Total website revamp (hopefully Jan 4th)
So, the very next task will be to release a Serializer firmware update with the heartbeat, and hopefully the functionality to talk to multiple Serializers from one serial port. This functionality has already been added to the product we're releasing on Jan 4th, and then I'll put it into the Serializer, which will just require testing, and no coding. Thanks Scott, you have a Happy Holiday/Merry Christmas too! Best Regards!
Jason Summerour
President,
Summerour Robotics Corporation
www.roboticsconnection.com
|
|
|
|