NP-41 Emulator (may be)

[Chris Chung]

(04-19-2016 01:57 AM)Sylvain Cote Wrote:  Hello Chris,

Sorry for not coming back sooner.

First, I do not have a Windows PC, I use a MacBook Pro running OSX v10.11 64 bits with Parallels v11 and a Windows 7 32 bits in a VM.
I have spent the last 2 hours trying unsuccessfully to update the unit and now I have fried my unit. 8-(
I was working on a antistatic mat with a grounded bracelet at all time

This is what I did ...
a) I have downloaded and installed the mspdebug-0.23-win32-signed.zip software
b) I have downloaded your firmwares
c) I have tried to use the command -> mspdebug rf2500 "prog np41.hex" but the software is not seeing the MSP430 through the USB port
d) mspdebug --usb-list return nothing
e) I then registered myself on TI website and downloaded the dev kit (msp430.dll_developer_package_rev_3.07.000.012.zip)
f) I then installed the VCP drivers and Windows now sees the MSP430 unit as COM7
g) mspdebug --usb-list still return nothing (as expected)
h) mspdebug rf2500 "prog np41.hex" still not working (as expected)
i) I then downloaded and installed the "Realterm_2.0.0.70_Signed_Wrapper_setup.exe" software
j) started RealTerm and he sees the COM7 with 9600,n,8,1
k) I have tried to go into the bootloader as instructed and tried multiple things (no battery)
-> physically disconnect/reconnect the USB cable with user key pressed (several times, never worked)
-> virtually disconnect/reconnect the USB cable with user key pressed (several times, never worked)
-> physically disconnect/reconnect the 6 pins cable from the calculator (once, this is what killed the unit)
L) Then I tried to insert a new battery but there is no response anymore

That was short!!

Best regards,

Sylvain

Hi Sylvian,

First of all, thanks for taking the time to try the unit out. We are geographically close enough that I can swap your unit quickly if we can't find a way to revive it. The new boards are on transit now.

I am not sure about VMing a windows image on an OSX, I had never own an Apple before (except the Apple Newton), but if it's windows on Linux, I already have trouble w/ the USBs.

If it appears that your unit has been "bricked", there can be two reasons. 1) bootloader lost power during critical section, where reset vectors are being written. 2) my bad soldering on SMD parts. 1) is not likely in my opinions as the critical sections is only 1 few tenths cycles wide and it doesn't look like the firmware download started. 2) is more likely as I had another failed unit w/ me right now.

There are several uncertainties to check out on why it doesn't work, despite the fact that your unit may have a h/w defect.

mspdebug w/ TI Launchpad G2
It appears that mspdebug never sees the LaunchPad. As when you do the --usb-list, it should show

Code:

chrisc@SW20101105A:~/ez430/breadboard_collections > mspdebug --usb-list
Devices on bus 000:
    000:000 0451:f432 eZ430-RF2500 [serial: 05FF4225A5103B56]

Also the need to download and install from TI the msp430.dll is not needed for the NP-41s, the LaunchPad G2 is very old and does not have programmer firmware upgrade capabilities. The msp430.dll is needed for Harald to program the NP-41 as the programming command is "prog tilib", instead of the "prog rf2500". So I believe although we can see a COM7:, mspdebug does not see the programmer. We can check windows "devices and printer" and the device should appears like so;

   

Now that I look at it, you may need to install "libusb" to get mspdebug to see the device. I forgot to mention it as I had libusb all along on my system and didn't thought of it.

If you want to try this and get mspdebug to see the device, re-attaching the unit via the Launchpad and just run "mspdebug rf2500" will allow us to see whether the unit has hardware failed (if mspdebug sees the launchpad device but failed to see the chip msp430g2955) or not (if mspdebug sees the chip, it will report the chip type, etc).

If it is not a hardware fail, the unit can be revive by re-programming w/ "prog hp41s-xxxx.hex"

Serial port / bootloader

We should also do quick testing to determine this COM7: is operational or not. By plugging and unplugging the Launchpad, do we see this COM7: come and go? This will confirm COM7: is indeed tied to the launchpad and is not a virtual / fake port.

If so, we can jumper short the Tx and Rx lines (i.e. 2 of the 6 wire jumpers) w/ metal tweezers, bobbin pins, etc. And w/ realterm opening the port, typing something should have your characters echo back. This way we can confirm that the serial channel (via the launchpad) is operational.

Re-attaching the unit to the launchpad. Unplug and re-plug the usb cable while holding the "User" key should get us into the bootloader mode. Pressing "@" key via Real-term should trigger the "@>" prompt for download. Of course if the unit hardware had failed, there would be no response.

Next Steps

I would suggest you don't put much thoughts on the unit as I will be able to swap it in a few weeks time. If you are interested and have time, you may want to try the above to see if the unit was bricked or just failed. The final product need to be re-programmed via the uart bootloader anyway. There should be some uart dongles that OSX can use and we should be using those, plus need to find a terminal program that can do binary downloads under OSX.