Quote from elmor on 2022-05-27, 14:49

Quote from shawn on 2022-05-27, 03:33

Hi Jon,

We now have our CMSIS-DAP adapter so we can test new FW, if you have a new binary available.

Thanks,

Shawn

Edit: The red circled pads are for SWD, correct?

Hello Shawn,

Yes correct. Actually SWD/SWC is also connected through the OLED header. The OLED itself may interfere with programming, so best to remove it first. 

OLED header SCL = SWD, SDA = SWC. You can also power the PMD from the CMSIS-DAP by connecting OLED header 3.3V and GND. You probably separately have to wire reset to the MCU pin#6.

Firmware for test: https://1drv.ms/u/s!Atmpv-6qHr_61-V7UWlpNQwEIBrpWQ?e=6LP46a

/Jon

Quote from shawn on 2022-05-28, 07:37

Thanks for the info + firmware.

Unfortunately I was not able to successfully flash firmware on the PMD even after double and triple checking all connections. I am going to try a different ARM CMSIS-DAP compliant debugger in the next few days.

Thanks,

Shawn

Quote from shawn on 2022-06-04, 06:56

Hi Jon,

I'm still not able to program our PMD. I scoped out the signals and clock / data / nreset do resemble something correct, and the red PMD LED does turn on briefly, but the SW tools indicate that no response was received from the device.

If I put in an order for 2-3 additional PMDs, is it possible to get the new firmware pre-flashed on them?

Thanks,

Shawn

Quote from elmor on 2022-06-06, 18:04

Quote from shawn on 2022-06-04, 06:56

Hi Jon,

I'm still not able to program our PMD. I scoped out the signals and clock / data / nreset do resemble something correct, and the red PMD LED does turn on briefly, but the SW tools indicate that no response was received from the device.

If I put in an order for 2-3 additional PMDs, is it possible to get the new firmware pre-flashed on them?

Thanks,

Shawn

Hello Shawn,

Ok it's supposed to be possible and works here with J-Link as long as reset signal is wired. Any newly ordered units will ship as the PMD-USB version, which both offers higher transfer rate (2 MBit/s) and firmware update capability as long as you're willing to talk to it using USB to PC instead of the previous I2C interface.

/Jon

Quote from shawn on 2022-06-08, 04:52

Hi Jon,

Good news - I was able to successfully erase / flash / verify (I think). I think my previous issue was that SWCLK was not held low after reset deassertion (so JTAG / SWD mode was not enabled). I was able to make it work with the following sequence:

1. Hold SWCLK + Reset low manually.
2. Release reset (leave floating).
3. Release SWCLK.
4. Flash.

Bad news - I still see the same issue with PMD.X.production_20220527_1330.bin. Here is a histogram, for reference (12V / 800mA load).

0000: 9884
0001: 2209
0002: 163
0003: 5
0004: 0
0005: 0
0006: 0
0007: 0
0008: 0
0009: 0
000a: 10
000b: 199
000c: 2370
000d: 13261
000e: 28846
000f: 27495
0010: 2560
0011: 489
0012: 35
0013: 1

I'm pretty sure that I am actually flashing the new image - I'm using edbg in verbose mode, it reports each step as it goes along, and programming seems to take several seconds. Also I see traffic on the SWD lines when flashing.

Is it possible that the FW race condition still exists?

Thanks,

Shawn

Edit: The "Firmware Version" read over I2C reads 5 on the newly flashed PMD.

Quote from elmor on 2022-06-08, 09:02

Quote from shawn on 2022-06-08, 04:52

Hi Jon,

Good news - I was able to successfully erase / flash / verify (I think). I think my previous issue was that SWCLK was not held low after reset deassertion (so JTAG / SWD mode was not enabled). I was able to make it work with the following sequence:

1. Hold SWCLK + Reset low manually.
2. Release reset (leave floating).
3. Release SWCLK.
4. Flash.

Bad news - I still see the same issue with PMD.X.production_20220527_1330.bin. Here is a histogram, for reference (12V / 800mA load).

0000: 9884
0001: 2209
0002: 163
0003: 5
0004: 0
0005: 0
0006: 0
0007: 0
0008: 0
0009: 0
000a: 10
000b: 199
000c: 2370
000d: 13261
000e: 28846
000f: 27495
0010: 2560
0011: 489
0012: 35
0013: 1

I'm pretty sure that I am actually flashing the new image - I'm using edbg in verbose mode, it reports each step as it goes along, and programming seems to take several seconds. Also I see traffic on the SWD lines when flashing.

Is it possible that the FW race condition still exists?

Thanks,

Shawn

Edit: The "Firmware Version" read over I2C reads 5 on the newly flashed PMD.

Hello Shawn,

Ok I'll have a look again. What was done now is that the value is latched when reading the lower byte of 0x80-0x8F registers, which one are you using for the above?

Ex:

1. Read 0x80 (updates latched value, returns latched PCIE1 Voltage low byte)
2. Read 0x81 (returns latched PCIE1 Voltage high byte)

Also works to send CMD 0x80 and read 2 bytes.

/Jon

Quote from shawn on 2022-06-09, 00:17

Hi Jon,

I was using register 0x05/0x06 for PCIE1 current. It sounds like the new latching scheme only applies for regs 0x8X / 0x9X? I will try 0x82/0x83 instead and post back results!

Thanks,

Shawn

Edit: My initial results show that using 0x82 (rather than 0x05) reduces the number of error / mismatch cases dramatically (factor of ~50x). I will gather histogram data using a known current load later today.

It looks like the major source of this issue is now eliminated! As for the remaining error source, is it possible that the latched 12-bit value isn't updated atomically (e.g., ADC in in the process of writing latest conversion at the same time we do a load, so we get one "old" byte and one "new" byte)? Is it worth trying something like this for the latching?

// assuming something like uint16_t latched_val, volatile uint16_t *latest_adc.

do { latched_val = *latest_adc; } while (latched_val != *latest_adc);

Edit2: Here is the histogram for fixed 800mA load:

0000: 105
0001: 28
0002: 3
0003: 0
0004: 0
0005: 0
0006: 0
0007: 0
0008: 0
0009: 0
000a: 6
000b: 249
000c: 2753
000d: 15217
000e: 34184
000f: 32132
0010: 12296
0011: 2649
0012: 181

As you can see, the error rate is > 50x lower than before, a big improvement.

FYI I am reading two bytes from 0x82 in this example.

Quote from shawn on 2023-05-10, 06:19

Hi Jon,

I would like to double check - is the register latching scheme for I2C 0x8X / 0x9X implemented in the latest shipping version of PMD-USB FW? We are considering to order several more units shortly and for a few reasons (mainly because we have already tested + validated the I2C interface), we still prefer the I2C interface rather than USB. Thanks.

Edit: Looking at the datasheet closer, I should have asked this question first: does the PMD-USB still support an I2C interface?

Quote from elmor on 2023-05-10, 11:19

Quote from shawn on 2023-05-10, 06:19

Hi Jon,

I would like to double check - is the register latching scheme for I2C 0x8X / 0x9X implemented in the latest shipping version of PMD-USB FW? We are considering to order several more units shortly and for a few reasons (mainly because we have already tested + validated the I2C interface), we still prefer the I2C interface rather than USB. Thanks.

Edit: Looking at the datasheet closer, I should have asked this question first: does the PMD-USB still support an I2C interface?

Hello Shawn,

The register latching is different for PMD-USB, much due to your feedback. Values are copied to a second buffer for sending over USB after an ADC update to prevent the above issue. Additionally there's a bootloader that allows for firmware updates on PMD-USB, meaning it's easier to patch this type of bug going forward.

Regarding the I2C interface, the PMD-USB does not support it by default. Depending on how important it is, I see two ways PMD-USB could be customized to support it. It would require flashing a modified version of the PMD firmware on it through the PMD-USB bootloader. Then the I2C interface could either be exposed using the OLED header (and lose OLED support) or you could remove the CH340N USB-to-Serial IC and solder the I2C wires directly to those pads (UART TX/RX pins are the same a previous SDA/SCL pins). The MCU used is the same except with double the flash memory meaning it's code compatible. If this would be a viable solution I can prototype it for you.