[2.66b0+] No GUI connection, 256000 baud too high
  • My SimpleBGC 32 extended CAN board needs to work with the new CAN drivers, so an up-to-date firmware is neccessary.
    It works with firmwares of 2.63 and below (it connects via USB and other serial connections).
    After updating to 2.66b0 or b2, it doesn't connect by any means.

    Board is NOT dead. Reacts to menu button presses.
    I clicked 8 times and 12 times. Both should reset serial interfaces, but obviously, they don't. It reacted (led), but gave no connection.

    Tried under Windows 7 and Linux (Ubuntu, kernel 4.10).
    From new GUI, I suspect the board now defaults to 256000 baud, not 112500 until now.
    Both OSes don't allow me to set higher serial speeds. No Windows driver, also not the Linux System.
    With cp210x kernel module, there's no way to set high speeds. It supports them in code, though.
    Setserial doesn't work at all with /dev/ttyUSB0, stty works, but doesn't allow high speeds.
    I have another USB-Serial bridge with high speed support, also failing with high baud rates.
    The GUI itself throws an error on java console when trying to set 256000 baud.
    I checked that the chip itself (cp2102 on board) was programmed to support high speeds. It does.
    I hacked the kernel module to substitute 38400 baud with 256000 baud, but Java gives an error with that.
    I found a Python script that can set the desired baud rate, but the GUI overwrites it when connecting.
    Thus, I do not see ANY way to connect the GUI to the board.
    Windows and Linux as a whole don't seem to like high serial speeds, all I found online was hacky and didn't work.

    I'm also not sure if the firmware works correctly. It is flashing panically and beeping endlessly like being in an alarm condition. With being powered by USB alone, this shouldn't happen. It should be in kind of a maintenance mode instead, as long as there's no external power.

    Previously, I flashed recovery firmware and wiped EEPROM to have a nice, fresh start.
    Thus, it doesn't see IMUs. While older (<= 2.63) were happily working without IMU panic, 2.66+ seems not to.<br />
    I'm open to proposals, as long as they address my problem thoughtfully.
    This can't be the only case where this happens, hmm ..
    Can someone possibly post the standard baud rate (after complete reset) of the 2.66 firmwares?


    (Caps just for you to notice early, not yelling)

    Non-working serial was because the board refuses any communication in panic mode.
    Yeah, quality software. On errors, don't give anyone a chance to find out what happened.
    I reported some of that issues some months ago, nothing improved. How'd I dare?

    So what happened?
    I can't directly go to 2.66. (sic) Yeah, why would I?
    I had to walk the complete update path. Find a low version that worked to initialize EEPROM, so no error condition breaks comms.

    In Detail:
    -> 2.60. Flash, init, calibrate, works.
    -> Update to 2.63. Works. No CAN devices accessible. Yeah.
    -> Update to 2.66b0. Works. No CAN devices accessible. Wtf?

    Here, things break again.
    -> Update to 2.66b2. Freak out light show.
    -> Downgrade to 2.66b1. Had a backup. Dead.

    Walked that road for a few times now, always hoping things would be better next time.
  • Hi,
    We just tested the loading of 2.66b2 from server to the "Extended" board. It works with the CAN_Drv and CAN_IMU as expected.

    Try to do following steps:
    1. Set "Service" - "Emergency stop" - "Restart after a pause" = 0 to prevent cycle reset
    2. Disconnect CAN devices and start firmware. If encoders are enabled - disable them. Or better, erase EEPROM using the "Board" menu. Do it on firmware that works. Then upgrade to 2.66b2 - will it start or not?

    We had reports that some "Extended" boards manufactured by our partners, failed to work with the latest firmware (2.65, 2.66). But as we have no samples of such board in our hands, we can not find a reason. Check that MCU is exactly the "STM32F303VCT6".
  • UPD: shorting of the CAN signal lines (cross-shorting or shorting to the ground or +5V) can make system fully unfunctional (even MCU does not start). Also, the absense of 100 Ohm terminator causes the same. Please check you CAN bus hardware connection.
    (We will fix it in next beta release to properly handle CAN hardware failure at system start).