Activation keys for RF430FRL152H and MSP430L092 compatibility.

[travisgoodspeed]

Howdy y'all,

I ran into some trouble using mspdebug on an RF430FRL152H chip. This chip is weird in that it is low voltage and in that it uses 4-wire JTAG but not SBW, so I used the modern (black) MSP-FET and an RF430FRL152HEVM board, which includes level conversion to 3V logic. Sadly it works in UniFlash and CCS, but not in mspdebug.

The root cause seems to be that mspdebug is always sending an activationKey of zero to DeviceHandleMSP430::identifyDevice(). According to chipinfo.db, the RF430FRL152H and a few other chips require alternate activation keys, such as 0x5aa55aa5, 0xffffffff and 0xa55aa55a. A single chip requires 0xdeadbabe.

% cat chipinfo.db| grep -i activation | grep -v 00000000
                        .activation_key = 0x5aa55aa5,
                        .activation_key = 0xffffffff,
                        .activation_key = 0xa55aa55a,
                        .activation_key = 0xffffffff,
                        .activation_key = 0x5aa55aa5,
                        .activation_key = 0xffffffff,
                        .activation_key = 0xa55aa55a,
                        .activation_key = 0xffffffff,
                        .activation_key = 0x5aa55aa5,
                        .activation_key = 0xffffffff,
                        .activation_key = 0xa55aa55a,
                        .activation_key = 0xffffffff,
                        .activation_key = 0x5aa55aa5,
                        .activation_key = 0xffffffff,
                        .activation_key = 0xa55aa55a,
                        .activation_key = 0xffffffff,
                        .activation_key = 0xdeadbabe,
                        .activation_key = 0xffffffff,

When the connection fails, it does with Error 5, Unknown Device.

% mspdebug tilib                  
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 Daniel Beer <[email protected]>
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.13.0.601 Copyright (C) 2013 TI, Inc.

Using new (SLAC460L+) API
MSP430_GetNumberOfUsbIfs
MSP430_GetNameOfUsbIf
Found FET: ttyACM0
MSP430_Initialize: ttyACM0
Firmware version is 31400000
MSP430_VCC: 3000 mV
MSP430_OpenDevice
tilib: MSP430_OpenDevice: Unknown device (error = 5)
tilib: device initialization failed
% 

A temporary workaround is to patch DLL430_v3/src/TI/DLL430/DeviceHandleMSP430.cpp in libmsp430 so that the activationKey is forced to an acceptable value.

int32_t DeviceHandleMSP430::identifyDevice (uint32_t activationKey, bool afterMagicPattern)
{
        const bool assertBSLValid = (activationKey == 0x20404020);

        #warning This is an ugly temporary fix.  Don't use it.
        //activationKey=0x00000000; //Default, doesn't work for the RF430.                                                                                                                                                                        
        //activationKey=0x5aa55aa5; //Works                                                                                                                                                                                                       
        activationKey=0xa55aa55a;   //Also works                                                                                                                                                                                                  
        //activationKey=0xffffffff; //Doesn't work.                                                                                                                                                                                               
        //activationKey=0xdeadbabe; //Doesn't work.                                                                                                                                                                                               

        printf("Identifying device for activation_key=%lx\n", activationKey);
...

With this ugly patch to libmsp430 in place, we can connect to the chip at the expense of breaking all other chips.

% mspdebug  tilib                 
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 Daniel Beer <[email protected]>
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.13.0.601 Copyright (C) 2013 TI, Inc.

Using new (SLAC460L+) API
MSP430_GetNumberOfUsbIfs
MSP430_GetNameOfUsbIf
Found FET: ttyACM0
MSP430_Initialize: ttyACM0
Firmware version is 31300601
MSP430_VCC: 3000 mV
MSP430_OpenDevice
Identifying device for activation_key=a55aa55a
Identifying device for activation_key=a55aa55a
Got memory.
MSP430_GetFoundDevice
Device: RF430FRL152H (id = 0x0182)
2 breakpoints available
MSP430_EEM_Init
Chip ID data:
  ver_id:         81e7
  ver_sub_id:     0000
  revision:       9a
  fab:            55
  self:           5555
  config:         22
  fuses:          55
Device: RF430FRL152H [FRAM]
...

Type "help <topic>" for more information.
Use the "opt" command ("help opt") to set options.
Press Ctrl+D to quit.

(mspdebug) 

I'm not quite sure what the proper way to fix this issue is, but I hope that these details are helpful. Perhaps libmsp430 needs to be given an explicit model number, or an extra flag is needed somewhere?

Cheers from Knoxville,

--Travis

[dlbeer]

Travis Goodspeed <[email protected]> writes:

I ran into some trouble using mspdebug on an RF430FRL152H chip. This chip is weird in that it is low voltage and in that it uses 4-wire JTAG but not SBW, so I used the modern (black) MSP-FET and an RF430FRL152HEVM board, which includes level conversion to 3V logic. Sadly it works in UniFlash and CCS, but not in mspdebug. The root cause seems to be that mspdebug is always sending an `activationKey` of zero to `DeviceHandleMSP430::identifyDevice()`. According to `chipinfo.db`, the RF430FRL152H and a few other chips require alternate activation keys, such as `0x5aa55aa5`, `0xffffffff` and `0xa55aa55a`. A single chip requires `0xdeadbabe`.

...

A temporary workaround is to patch `DLL430_v3/src/TI/DLL430/DeviceHandleMSP430.cpp` in `libmsp430` so that the `activationKey` is forced to an acceptable value. ```C++ int32_t DeviceHandleMSP430::identifyDevice (uint32_t activationKey, bool afterMagicPattern) { const bool assertBSLValid = (activationKey == 0x20404020); #warning This is an ugly temporary fix. Don't use it. //activationKey=0x00000000; //Default, doesn't work for the RF430. //activationKey=0x5aa55aa5; //Works activationKey=0xa55aa55a; //Also works

Hi Travis, Does it also work if you change, in mspdebug's drivers/tilib.c, the following line: if (tilib_api->MSP430_OpenDevice("DEVICE_UNKNOWN", "", 0, 0, 0) < 0) { to: if (tilib_api->MSP430_OpenDevice("DEVICE_UNKNOWN", "", 0, 0xa55aa55a, 0) < 0) { I haven't had a chance to look into it too deeply yet, but it looks to me like the second-last argument eventually makes its way to the first argument of identifyDevice (but I might be wrong). Not sure how to go about determining the correct value automatically in any case yet, because we won't know the device ID to look up until after OpenDevice succeeds. Maybe we'll have to require the user to specify it on the command-line in some cases. Cheers, Daniel

…

-- Daniel Beer <[email protected]> http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

[travisgoodspeed]

It would be rather inconvenient to demand the chip's model number before the fact, especially for projects like my GoodWatch whose firmware can run on more than one model number. Perhaps it will be good enough to make "DEVICE_UNKNOWN" the default?

I hope to have time this weekend to come up with a clean fix for you. Quick experiments last weekend with your suggested fix didn't seem to work, but I didn't have time then to investigate it further.

[dlbeer]

Travis Goodspeed <[email protected]> writes:

It would be rather inconvenient to demand the chip's model number before the fact, especially for projects like my GoodWatch whose firmware can run on more than one model number. Perhaps it will be good enough to make `"DEVICE_UNKNOWN"` the default?

Yeah, I don't think we'd want to break anything that currently works. I was thinking that perhaps we could reuse the --fet-force-id option's argument in the tilib for this purpose, but just go with the current behaviour if nothing is specified.

I hope to have time this weekend to come up with a clean fix for you. Quick experiments last weekend with your suggested fix didn't seem to work, but I didn't have time then to investigate it further.

I might have time to look into this next weekend, but I don't have any hardware to test with. I guess I can at least check for a method of influencing the argument that needs to change via the library's C API. Cheers, Daniel

…

-- Daniel Beer <[email protected]> http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B