tilib: MSP430_OpenDevice: Device database not loaded. (error = 98)

[zacharyvincze]

I'm encountering a very weird issue right now in which I have no clue how to solve. When I run mspdebug tilib it gives me the following output. It can also be noted that I'm running this on a Raspberry Pi 2.

MSPDebug version 0.24 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2016 Daniel Beer <dlbeer@gmail.com>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.

Using new (SLAC460L+) API
MSP430_GetNumberOfUsbIfs
MSP430_GetNameOfUsbIf
Found FET: ttyACM2
MSP430_Initialize: ttyACM2
Firmware version is 30901602
MSP430_VCC: 3000 mV
MSP430_OpenDevice
tilib: MSP430_OpenDevice: Device database not loaded. (error = 98)
tilib: device initialization failed

As you can see from the output, I've installed the newest version of libmsp430.so. I have a strange feeling that that's what's causing the problem.

Any help with this would be great.

[dlbeer]

On Wed, Jan 18, 2017 at 07:42:08PM -0800, Zachary Vincze wrote:

I'm encountering a very weird issue right now in which I have no clue how to solve. When I run mspdebug tilib it gives me the following output. It can also be noted that I'm running this on a Raspberry Pi 2.

MSPDebug version 0.24 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2016 Daniel Beer <dlbeer@gmail.com>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.

Using new (SLAC460L+) API
MSP430_GetNumberOfUsbIfs
MSP430_GetNameOfUsbIf
Found FET: ttyACM2
MSP430_Initialize: ttyACM2
Firmware version is 30901602
MSP430_VCC: 3000 mV
MSP430_OpenDevice
tilib: MSP430_OpenDevice: Device database not loaded. (error = 98)
tilib: device initialization failed

As you can see from the output, I've installed the newest version of libmsp430.so. I have a strange feeling that that's what's causing the problem.

Any help would this would be great.

Hi Zachary,

That looks like something wrong with either the library or the FET. It's possible that it's architecture-specific. Have you tried running mspdebug with the equivalent x86 version of libmsp430.so on a PC to see what happens?

Do older (or just other) versions of libmsp430.so work on the Pi?

Cheers, Daniel

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

[ghost]

Hi! I am seeing this same result trying to use 0.24 (cloned from github on Jan 24, 2017) on an x86_64 host with Ubuntu linux and a self compiled version of TI's libmsp430.so.

Interestingly the versions of mspdebug included in Ubuntu 16.04 & 16.10 (Ubuntu DEB versions 0.22-2 and 0.22-2build1 respectively), both work to connect to a MSP-EXP430F5529LP, although the registers shown after it is started appear to be corrupted... (the PC after a reset is set to 0xBA9CD54 for example)

The steps I took to test 0.24 were on a Ubuntu 16.04 AMD64 host:

git clone of the source from git hub. cd mspdebug make LD_PRELOAD_PATH=/dir/with/libmsp430.so mspdebug tilib

Let me know if there's any info i can supply and thanks for the great program btw!

[dlbeer]

On Tue, Jan 24, 2017 at 09:27:44PM -0800, typerrrrrrrr wrote:

Hi! I am seeing this same result trying to use 0.24 (cloned from github on Jan 24, 2017) on an x86_64 host with Ubuntu linux and a self compiled version of TI's libmsp430.so.

Interestingly the versions of mspdebug included in Ubuntu 16.04 & 16.10 (Ubuntu DEB versions 0.22-2 and 0.22-2build1 respectively), both work to connect to a MSP-EXP430F5529LP, although the registers shown after it is started appear to be corrupted... (the PC after a reset is set to 0xBA9CD54 for example)

The steps I took to test 0.24 were on a Ubuntu 16.04 AMD64 host:

git clone of the source from git hub. cd mspdebug make LD_PRELOAD_PATH=/dir/with/libmsp430.so mspdebug tilib

Let me know if there's any info i can supply and thanks for the great program btw!

In that case, would you be willing to try a git-bisect between 0.22 and the current version?

If you can pin it down to one commit then it should (hopefully) be easily fixable.

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

[ghost]

For sure! I tracked it down to the following (it's worth noting that all of the "good" commits still showed corrupted registers, which I'll also paste below):

~/MSP430/mspdebug$ git bisect good f1f513e01318cc9729873966ccedb733a0c131fa is the first bad commit commit f1f513e01318cc9729873966ccedb733a0c131fa Author: Daniel Beer dlbeer@gmail.com Date: Wed Jun 10 12:31:08 2015 +1200

tilib_api: add support for SLAC460L API.

:040000 040000 1b3dd2f99e4a5df0173546f6b55651142eaa5e88 6659580a5c7dc03779bf5e94d42877cb24117518 M drivers

Here is a sample of the registers after the MSP430F5529 is connected to, the board just has on the stock factory code, and I would expect the PC to be somewhere right around 0x02400. If you would like this opened as a separate issue, I'll do that (maybe after the connection issues are sorted?):

(mspdebug) reset (mspdebug) regs ( PC: 45bceff8) ( R4: 469f5608) ( R8: 2012bb0) (R12: 46a35700)
( SP: 2031290) ( R5: 00001) ( R9: 41b626) (R13: 3e5d01a8)
( SR: 2031788) ( R6: 3e597750) (R10: 0053b) (R14: 3e5d02b0)
( R3: da046300) ( R7: 00001) (R11: 413221) (R15: 4681847b)
0x45bceff8: 45bceff8: 50 77 59 3e SUBC.B 0x3e59(R7), PC 45bceffc: fe 7f 00 00 SUBC.B @R15+, 0x0000(R14) 45bcf000: 01 00 MOVA @PC, SP

[dlbeer]

On Wed, Jan 25, 2017 at 08:47:52PM -0800, typerrrrrrrr wrote:

For sure! I tracked it down to the following (it's worth noting that all of the "good" commits still showed corrupted registers, which I'll also paste below):

~/MSP430/mspdebug$ git bisect good f1f513e01318cc9729873966ccedb733a0c131fa is the first bad commit commit f1f513e01318cc9729873966ccedb733a0c131fa Author: Daniel Beer dlbeer@gmail.com Date: Wed Jun 10 12:31:08 2015 +1200

tilib_api: add support for SLAC460L API.

:040000 040000 1b3dd2f99e4a5df0173546f6b55651142eaa5e88 6659580a5c7dc03779bf5e94d42877cb24117518 M drivers

Here is a sample of the registers after the MSP430F5529 is connected to, the board just has on the stock factory code, and I would expect the PC to be somewhere right around 0x02400. If you would like this opened as a separate issue, I'll do that (maybe after the connection issues are sorted?):

(mspdebug) reset (mspdebug) regs ( PC: 45bceff8) ( R4: 469f5608) ( R8: 2012bb0) (R12: 46a35700)
( SP: 2031290) ( R5: 00001) ( R9: 41b626) (R13: 3e5d01a8)
( SR: 2031788) ( R6: 3e597750) (R10: 0053b) (R14: 3e5d02b0)
( R3: da046300) ( R7: 00001) (R11: 413221) (R15: 4681847b)
0x45bceff8: 45bceff8: 50 77 59 3e SUBC.B 0x3e59(R7), PC 45bceffc: fe 7f 00 00 SUBC.B @R15+, 0x0000(R14) 45bcf000: 01 00 MOVA @PC, SP

Ok. The corrupt registers is a known issue -- it's due to TI changing the library ABI for 64-bit machines from SLAC460L onwards. What the tilib driver now does is probes the library to see what version it is before deciding how to call it. This is in drivers/tilib_api.c, where we construct thin wrappers with a common internal interface for each library call we're interested in.

However, it looks like something else has changed since then. I'm guessing it's something minor (maybe an unspecified argument that happens to come out right when using the old version), but it might take a bit of digging to find.

I'm unfortunately not able to look into it right now, but if you wanted to have a go at it, your best bet would be to track down the header files for both SLAC460L and the version you have (SLAC460S), and look for a difference in the prototypes of the functions that are called during initialization (the MSP430_* calls named in mspdebug's output).

Let me know if you have any questions in the meantime.

Cheers, Daniel

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

[ghost]

Ahhh... Okay, yeah, definitely differences... The old API definitions used long's (64bits on most systems) for much of the interface:

STATUS_T TIDLL (*MSP430_Initialize)(char *port, long *version);

And the new interface has largely replaced these with int32_t's:

int32_t TIDLL (*MSP430_Initialize)(char *port, int32_t *version);

On version 0.22 MSP430_Initialize reports: Firmware version is 4294967294 (2**32 - 2), which is a perfectly fine positive long (64bits).

When I try and attach on 0.24 I get: FET firmware update is required.

Which after a bit of snooping is because the returned version number is -2 (which is the same number as above but as a int32_t).

I haven't had time to look at what all would be affected by the size change. But at least have a bit of a clue :) I'm hoping to have some time over the weekend to take a closer look, thanks for the pointers!

[dlbeer]

On Thu, Jan 26, 2017 at 11:04:49PM -0800, typerrrrrrrr wrote:

Ahhh... Okay, yeah, definitely differences... The old API definitions used long's (64bits on most systems) for much of the interface:

STATUS_T TIDLL (MSP430_Initialize)(char port, long *version);

And the new interface has largely replaced these with int32_t's:

int32_t TIDLL (MSP430_Initialize)(char port, int32_t *version);

On version 0.22 MSP430_Initialize reports: Firmware version is 4294967294 (2**32 - 2), which is a perfect fine positive long.

When I try and attach on 0.24 I get: FET firmware update is required.

Which after a bit of snooping is because the returned version number is -2

I haven't had time to look at what all would be affected by the size change. But at least have a bit of a clue :) I'm hoping to have some time over the weekend to take a closer look, thanks for the pointers!

Yes, that's all correct -- but the STATUS_T vs int32_t return value change was one of the differences introduced with SLAC460L, which should be handled correctly by the tilib_api wrapper. I think your transcript showed the new API being detected and used in mspdebug 0.24, so that particular issue shouldn't be the cause of the failure.

That's not to say that a similar issue isn't to blame though. Maybe there's been some additional change between SLAC460L and SLAC460S of a similar kind which happens not to break in the same way if you assume the old API.

Cheers, Daniel

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

[CrazyCasta]

I'm pretty sure this is what 0666a32517315ee1f802c9aeca9fbe021afc748d fixed as I ran into the same problem, missed that commit and independently fixed it. zacharyvincze can you confirm? Also, seems typerrrrrrrr's problem is different.