search

kanflo / opendps

Give your DPS5005 the upgrade it deserves
MIT License
891 stars 124 forks source link

Cannot upload firmware #191

Open hseibel12 opened 5 years ago

hseibel12 commented 5 years ago

I've been trying to upload a new firmware with latest version. I think the function has get broken. When starting upload in verbose mode the software starts initialisation block and then transfers the first block successfully. The second block also starts uploading, but then breaks. You cannot get any command working without resetting the device.

Here a brief copy of the communication:

Communicating with /dev/ttyUSB0 TX 9 bytes [7e 09 04 00 2f b2 f3 cc 7f] RX 9 bytes [7e 89 00 04 00 03 66 0f 7f]

Download progress: 2% Communicating with /dev/ttyUSB0 TX 1036 bytes [7e 0a f0 1f 00 20 a1 .... ....b9 fe e7 94 78 00 2c ae c2 7f] RX 6 bytes [7e 8a 00 f4 53 7f]

Download progress: 4% Communicating with /dev/ttyUSB0 TX 1035 bytes [7e 0a 5e d0 4c 1e... ....f1 01 0f 0d d0 21 89 68 1e 71 18 7f] Error: timeout talking to device /dev/ttyUSB0.

From this point on there is no responce from opendps and you cannot communicate any longer. You need to power-cycle the device to restart. After that it runs for other commands but upload fails again.

Xenoamor commented 5 years ago

Can you try adding -b 115200 as a flag to dpsctl when you upload the firmware?

hseibel12 commented 5 years ago

Same behavior and same error! I changed Baudrate in MAKEFILE (opendps, dpsboot) to 115200 and also added -b 115200 Flag.

I know that this upload worked in one or two former versions very well because I used it very often when writing a class similar to DPSCTL in Visual Studio (.NET).

hseibel12 commented 5 years ago

Have tested. Does not work either . Same behavior.

Am 18. Oktober 2019 12:03:09 schrieb Xenoamor notifications@github.com:

Can you try adding -b 115200 as a flag to dpsctl when you upload the firmware? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Xenoamor commented 5 years ago

What DPS model is this? Also how are you connecting to the serial port, are you using any interface board between it and the PC, some of these models come with opto isolators boards

polihedron commented 5 years ago

Same issue here, DPS5015 rev 2.3, checked two usb to serial boards, one from DPS kit, second ftdi232, commands are working without errors, but I can't upload new firmware. Maybe one month ago it was working. opto isolators board: `dpsctl.py -d /dev/ttyUSB0 -v -U opendps.bin Communicating with /dev/ttyUSB0 TX 9 bytes [7e 09 04 00 a2 a4 ec ff 7f] RX 9 bytes [7e 89 00 04 00 03 66 0f 7f]

Download progress: 1% Communicating with /dev/ttyUSB0 TX 1035 bytes [7e 0a f0 1f 00 20 e9 6f 00 08 e7 6f 00 08 e5 6f 00 08 e5 6f 00 08 e5 6f 00 08 e5 6f ............. 00 00 b9 fe e7 94 78 00 2c e6 1d 7f] Error: timeout talking to device /dev/ttyUSB0.`

ftdi232 chip board: `dpsctl.py -d /dev/ttyUSB0 -v -U opendps.bin Communicating with /dev/ttyUSB0 TX 9 bytes [7e 09 04 00 a2 a4 ec ff 7f] RX 9 bytes [7e 89 00 04 00 03 66 0f 7f]

Download progress: 1% Communicating with /dev/ttyUSB0 TX 1035 bytes [7e 0a f0 1f 00 20 e9 6f 00 08 e7 6f 00 08 e5 6f 00...............................84 00 00 b9 fe e7 94 78 00 2c e6 1d 7f] Error: timeout talking to device /dev/ttyUSB0.`

hseibel12 commented 5 years ago

Have been trying to test even deeper into the problem. Unfortunately I only have basic skills in C-programming. I put some debug-outputs to different points in the communication in dpsboot.c I found that communication works just before flashing the first block of new data. So it might be possible that flashing new firmware is the problem behind it.

Also, an older version works very well. I don’t know the reason but for me it seems to be a problem after doing some housekeeping with the code. Older version, that I mentioned, still uses the PACK- / UNPACK-macros. This version are running. Same as polihedron stated.

Xenoamor commented 5 years ago

Possible regression caused by #176 I'll have a look into it

Xenoamor commented 5 years ago

Hmmm.. I'm unable to reproduce this with c548a92ee5ef0424ced7c079b52a8e0ce1cbd180. I don't have a way of upgrading the bootloader at the moment though so perhaps the issue lies there

edit: perhaps we should revert this change for the bootloader only? I can't seem to spot where this is failing but I'm also not familiar with dpsboot

kanflo commented 5 years ago

I am having a look into it right now. Will try all combinations of boot loader/app pre/post #176.

kanflo commented 5 years ago

Bummer, reopening...

kanflo commented 5 years ago

Weeeeell, this was a rather disappointing Sunday outing for me. I am using macOS which means a world of pain nowadays when it comes to serial devices. FTDI support is wonky so I am using a Black Magic Probe. My Mojave machine crashes when running dpsctl and the older High Sierra machine lies to me. PySerial write(...) claims to have written data that neither the STM32 receive nor are are visible on my oscilloscope. Yes, I brought my trusty old Rigol out to debug this.

I am taking a brake for coffee now and see if I can find a proper Linux machine.

hseibel12 commented 5 years ago

Hi Johan, I am using VirtualBox & Linux. Works well on a Windows machine. FTDI adapter are quite well supported .

Xenoamor commented 5 years ago

You can use the "Windows Subsystem for Linux" on Windows 10 and avoid the virtual machine altogether. Saves having the slow down caused by virtualisation

kanflo commented 5 years ago

I got it going, sort of. I loose a bunch of frames from time to time which reminds me to stabilise the UART upgrade protocol, will open separate issue.

Xenoamor commented 5 years ago

Interesting, any idea why you're loosing frames? Is the RX buffer too small?

kanflo commented 5 years ago

Using a logic analyser I see that the data Pyserial claims have been written never reaches the TX line. TX stops moving in the middle of a frame and is silent for a few retries (due to RX timeout) and then suddenly starts moving again. I blame Apple for this one. On the flip side I got the perfect opportunity to stabilise the UART protocol...

hseibel12 commented 5 years ago

I am using another debugging method and it workes quite well for me: I have collected all the strings dpsctl is going to report in verbose mode. Then I change to HTERM (the Hammer-Terminal) where I am able to insert the hex-string in sending dialogue and then looking for the answer. I found that the first block of firmware data was sent (and recieved) successfully. I could verify that the decice is still responding by sending another commend i.e. the query. When trying to send the next step the error occurs. So it breaks behind the first data block. Should we reduced the length of the sending block to, let's say 512 bytes?

kanflo commented 5 years ago

256 bytes works for me. I think I saw a number of buffer overruns in the code but need to look more carefully in the coming week.

kanflo commented 5 years ago

Additionally, If I send a 512 byte frame I end up getting a SIGSEGV in memcpy(frame->buffer, data, status) called from uframe_extract_payload(...) on the reception of the 512 byte frame. Not that strange given the following struct:

#define MAX_FRAME_LENGTH (128)
typedef struct 
{
    uint8_t buffer[MAX_FRAME_LENGTH];
    uint32_t length;
    uint16_t crc;
    uint32_t unpack_pos;
} frame_t;

So, anything above 128 byte chunks might cause a crash.

Additionally, sending a 512 byte frame bricks my boot loader :-/ When writing the past_upgrade_started unit, the byte at 0x08000007 changes from 0x08 to 0x00.