Hi,
My mistake, I set the baudrate for UART1 to 1843200 (the highest setting) in U-Center. Now I can no longer connect via U-Center except in Safeboot.
I can safely enter safeboot, but there is no downloadable firmware available to flash. I dont know how to recover the board from this.
Other UART1 settings will permit me to recover using the “Revert” button, but not this one.
Can you help me?
Kind regards
Mick
Try to use the U-Center to manually adjust the UART1 settings and change the baud rate back to a more standard value like 9600 or 115200.
Unfortunately that doesnt seem to work.
Do you mean in Safeboot or otherwise?
The auto baud selection will not find the board and eventually ends on the default but without a connection.
In safeboot I can connect by strapping the pin to ground, but I cannot change the baud rate from there, either with the pin still grounded or released.
I fear a reflash of the firmware may be the only answer.
Have you experienced this problem yourself?
Mick
I should probably also add that its U-Center 2
I also still get a fix light so I believe the actual ublox chip is still functioning fine and its just the com port that may well be broken.
The boards are relatively economical, but I would certainly advise anyone not to select the maximum baud rate in U-Center 2. All other baud rates worked fine for me and were recoverable back to default config.
I have a number of boards and will not use the setting again, 460800 baud works fine as did 921600. 1843200 baud appears to have killed the com port, or its that busy (fast) it cant respond to -Center 2 trying to connect.
Hopefully someone else has experienced this and has a way back for these boards. For now, I have 2 which may well need to be firmware updated or reflashed with the current firmware before I can get them working again. For now they will have to sit in a bottom drawer.
uCenter Classic should also be usable. I’d suggest going into SAFEBOOT, and flushing setting via UBX-CFG-CFG methods
There are several USB to Serial adapters that are not capable of higher speeds, I’ve got some M10 on Prolific chips where the driver just blocks them.
Clive,
Thanks I will give that a go, I was editing the post above when you posted.
Mick
All I have managed to do to date is use the firmware tool to erase the flash. This now means the device will connect at the default baud rate. The device settings remain unusable, rather than try and go through them line by line, these boards (x2) will go in a bottom drawer until a firmware update is released. I think that is my only option.
This is the message I get when trying a revert:
devices/deviceCfgRevertError
nak
Clive, can you please ensure someone enters the acceptable settings for UART1 in the support documentation? (I have assumed you work for SparkFun)
I could find nothing that indicated the 1843200 baud rate would break the board. Given that UART is the only option on board, testing it to check maximum data transfer rate was what casued this issue.
If the current firmware is available anywhere to reflash it, I would be grateful. Your help has been appreciated.
I don’t, and not for u-Blox either, although I do maker support over there, and STMicro. I lurk here because there’s a lot of spill-over and cross-posting.
I’m assuming you’ve got this board, and there’s a limitation on the CH340G or it’s drivers.
I thought it went higher, covering 230400, 460800, 921600, 1500000, 2000000 baud
I’d have to check where the PL2303xx gets stuck, 460800 and above I’m reasonably sure.
The trick would be to set the configuration in RAM, until verified, that way you can recover via a power cycle.
I have the firmware, but reflashing is not the remedy, the settings can be cleared short of nuking the site from orbit…
Clive,
Thanks, apologies for assuming!
Yes thats the board.
The wiping of the flash has left me with a solid PPS light, in U-Center 2 quick config only GPS (G) is enabled on L1CA - there are no other entries.
Without wiping the flash I couldnt even connect to the board.
Trying to load any of the example configs fails (vehicle tracker, person tracker etc)
I appreciate that this might be recoverable with sufficient time but given the price its probably just better to carry on my work with another board and fix these later with a firmware upgrade.
Or to load a good board and compare line by line. When I have the time.
This issue is self inflicted through trial and error with the baud rate. I kick myself for trying the config twice and losing 2 boards. My lesson has been learned the hard way. Thankfully I have more boards.
Thanks again for the advice. It really has ben appreciated.
Take care (especially with baud rate 
)
Mick
At the higher rates one of the issues I see is that the list of “preferred” rates in the different softwares and drivers isn’t entirely consistent.
Frequently the bandwidth limits on the RS232 side came from the level converters, the most effective of those topped out below 1Mbps, and those with less performance/capacitance substantially below that. Now it does appear like a lot of the USB-to-CMOS Serial adapters also have lower limits than one might reasonably imagine, and whether that’s a function of lower power, or self clocking and rate accuracy, I don’t know, but the datasheets for assorted parts were all over the map when it comes to supported rates. On the uBlox side the rates are very flexible, not a fixed set of supported dividers, so on an MCU to receiver basis you should be able to use anything that takes your fancy up to several Mbps. Although the integrity of async serial is not fantastic. For high rates I’d use 2 stop bits to allow for quicker recovery. The receiver can also fire-hose out data using DMA, so the MCU needs to be ready and capable of sinking the data, and buffering independently of the parsing, so that doesn’t create it’s own bubbles in the pipeline.
Edit: Ok so Discourse allows for longer term edits, so I’ll add here
So with a Beitian BM-610, an M10 based G-Mouse, with a Prolific PL2303SA, which only supports rates up to 115200. So at the WIN32 API level it reports an error to set higher speeds, so for example 460800 and 921600 are offered in many apps, but are not successful when attempted, where as the receiver will accept and move to much higher, non-magic/preferred, baud rates.
On the uBlox side perhaps use the 0x40520001 CFG-UART1-BAUDRATE (RAM) setting via “Generation 9 Configuration View” or UBX-CFG-VALSET on uCenter Classic, so a power cycle recovers the receiver, avoiding the SAFEBOOT and UBX-CFG-CFG settings clearance.
The EVK-M101 has an RS232 connection spliced with a port off an FTDI QUAD UART, here I was able to configure the M10 and the USB COM port to 2000000 baud (2Mbaud), and was usable in uCenter Classic via custom baud settings. Now I wouldn’t anticipate the RS232 being viable.
CH340C should support 1Mbaud, per mickh and perhaps 1.5Mbaud and 2Mbaud, if borderline, perhaps try 8N2
After further testing I can confirm 1500000baud is stable at high rate on the U-Center ver1 display.
2000000baud is better with 8N2 but still appears to drop the odd data packet, but remains better than 8N1.
How they perform with connections to devices other than U-Center remains to be seen, but at least I now have a baseline for fast data work with this board.