Open maribu opened 1 year ago
Would this be a sensible workaround:
diff --git a/drivers/fet_core.c b/drivers/fet_core.c
index 9f426ba..7fa3fa4 100644
--- a/drivers/fet_core.c
+++ b/drivers/fet_core.c
@@ -344,6 +344,7 @@ static int identify_olimex(struct fet_device *dev, const char *force_id)
ramSize, ramSize / 1024);
show_dev_info(r->name, dev);
+ dev->base.chip = chipinfo_find_by_name(r->name);
if (fet_proto_xfer(&dev->proto, C_IDENT3,
r->msg2b_data, r->msg2b_len, 0) < 0)
(So populating the chip info based on what the Olimex detected?)
Ahh, I see that getconfigfuses()
is not implemented for the Olimex, hence fuses will always be 0x00
. For that reason device identification is bound to always find the family member with .fuse == 0x00
.
So instead populating the chip info based on the MCU name the Olimex JTAG detected is indeed sensible, right?
Hi,
when I connect an Olimex MSP430-JTAG-TINY-V2 to an MSP430F2618 (in the MSP430H2618 header board) I get the following output:
Note that it is first detected correctly as F2618, but then based on the Chip ID data incorrectly as F2619. When looking at the
chipinfo.db
, the reason obvious:Other then the fuses, the ID data of the MSP430F2618 and MSP430F2619 are identical. And the read fuses match the database entry for the F2619 and not of the F2618.
I used the following patch to use the now native XML export feature of the MSP Debug Stack in version 3.15.1.1 (the
chipinfo.db
was created from version 3.15.0.1) to double check if there was just an issue:And I get the same ID data:
So if the MSP Debug Stack in version 3.15.0.1 had incorrect fuses data for the MSP2618, it still has the same issue in the latest version - which I consider unlikely.
So I assume that the chip should have a fuses value of
0x1
. Do you have idea what the cause of the mismatch in the fuses data could be?I have to point out that after updating the firmware of the Olimex MSP430-JTAG-TINY-V2 debugging seems to work quite reliable (before updating the firmware even a simple reset didn't work; if you try to reproduce and have the hardware at hands you likely want to update the firmware first).
I could just pass
--fet-force-id MSP430F2618
, but I really would like to the tool to be able to detect the chip automatically. In fact, I'm working on a PR to letmspdebug
allow adding an--expected-device <DEV-ID>
so thatmspdebug
refuses to flash when the MCU detected doesn't match what is expected. This allows a build system that both handles building applications and flashing to ensure the correct firmware is flashed.