Logomatic V2 not programming on USB detachment

I was wondering if anyone has had this happen?

Have had V2 working well for about 2 weeks. Just today, I programmed it using the bootloader, and then unplugged the usb connection, expecting it to find the FW.SFE file (as usual) but nothing happened. No flashing lights to suggest it was my program at fault! Interestingly, the FW.SFE file is still on the uSD card.

I went to delete the file from the uSD card in order to try again with another FW.SFE but the PC wouldn’t recognise the drive. MMMmmm.

I took the uSD card out of the Logomatic and put it into the PC - no problem.

When I went to put the card back into the V2, the card would not ‘click’ into the socket!

Maybe the socket is gone bye-bye, and there is no connection(physical? electrical?) to the V2.

Any thoughts?

The uSD card can be read and written to using the PC…

I got the uSD socket ‘clicking’ when the card is placed in…

I wonder if the bootloader is still functioning on the ARM? The USB LED still activates with power on and I think that might be controlled with the bootloader, but I’m not sure. The charge circuit still works so that’s also good.

The FW.SFE file is still present on the card after power cycling…

How can I re-flash the bootloader onto the ARM?

Do I need a JTAG cable to do that? How does Sparkfun do it when they make it?

OK. Reading the bootloader tutorial. Gotta use a cable. LPC serial port programmer.

What about a magic wand? That could work…

I know, I’m just talking to myself now, but it helps…

ozzyace - I’m in a similar situation with FW.SFE not being loaded after disconnecting the USB. So I’m stuck.

Did you fix your problem? Any info is appriciated.

Thx

No I haven’t. I decided against the arm setup for the moment. But I have got the LPC serial port programmer, and I would like to try to re-load the bootloader back on. It’s all sitting unwrapped in the workshop. I looked into the arm as a replacement for a pic/vdrive2/rtc setup. I am alot more familiar with the pic and just couldn’t afford the time investment getting the arm up and running. I have a day free next week, so I’ll give the arm another try - and let you know. Just in case I don’t get back to you in a week, feel free to jab me in the ribs with another post!

Not sure if this is needed now but it might help:

viewtopic.php?p=81450&sid=aaa95424642ec … b02d#77764

Several names come up often with what look like good answers to things, but Kwan’s posts seem especially lucid and free of assumptions about what we might already know, and still manage to cut to the chase. His description of the order of events when connecting, starting firmware, or changing it, are as clear and correct as I’ve seen, and match what I found for myself.

I wish the original Logomatic docs were as clear and complete. Like me at first, I saw a post from someone who wasn’t clear whether the Logomatic could run on USB power. He (like me at first) wondered why it wasn’t logging or making its config file and first log file. Reasonable thought, if you know that USB can safely provide the 100 mA the Logomatic needs, so we are NOT stupid if we do not understand why the Logomatic can’t also run this way.

My point is that the Logomatic v2 is sorely weak in its initial support and documentation, and the firmware errors that cause “Saftey On” in LOGCON.txt, and the first log file to be called LOF01.txt are singularly uninspiring to newcomers who expect competent coders to spell correctly and not be lazy, given how intolerant computers are of errors in input. If we must avoid such weakness, those who expect us to learn for ourselves should not show it.

There isn’t even a freely available copy of the original firmware in binary format (FW.SFE) for us to easily revert to in case our first coding efforts fail, this being something I’ve found THREE places already to add weight to in demands that this be fixed. So here’s a fourth, now… I’ll let it rest and wait now but I really hope that someone makes it easier for beginners to be more self-reliant at the outset! It’s an awesome board, but very frustrating to see so quickly that its full potential is NOT realised, and to find it so hard to start to DO something about that. The starting conditions really need to be better than they are now.

Update: Jim (and Pete) at Sparkfun has sorted this, the original firmware now includes the file FW.SFE as explained to, and linked to, in the quoted bit of mail below:

I updated the firmware download

(http://www.sparkfun.com/datasheets/Widg … -v2wFW.zip)

online to include FW.SFE, so that should be taken care of.

http://www.sparkfun.com/commerce/produc … ts_id=8627

Links ADDED because it is apparently impossible to make UBB URLs work in that quoted text.

http://www.sparkfun.com/datasheets/Widg … -v2wFW.zip

http://www.sparkfun.com/commerce/produc … ts_id=8627

Hi All,

I am experiencing a similar issue to that noted by ozzyace.

My Logomatic was working well for several days of software development, but on the last attempt, the FW.SFE file was not flashed into the LPC2148. The processor does not appear to be running the application that was in it, prior to the failed load attempt.

I can still access the uSD card as a mass storage device, and have confirmed the formatting as FAT16.

I have tried to load the FW.SFE for my modified application, and when that did not work, I tried to load the FW.SFE from Sparkfun for the Logomatic - still no joy.

I don’t have a serial debug port connected, which is something I will have to try, to get some internal visibility on what is happening.

I don’t want to attempt to reflash the bootloader, if possible. Is there some internal vector table that may have been corrupted by an errant pointer in my code?

Any advice is appreciated.

Thanks in advance for your help,

This exact same thing is happening to me but on the Package Tracker. I guess I have bricked it ?

When I reset the the Package Tracker, nothing happens. If I plug it back into the Mac, the firmware is still there.

It did work for a few days and the upload, reset, boot loader sequence was fine. But then I started to get more and more problems. And now, nothing.

I’m suspecting hardware. I’m leery about getting another…

J

DTS_AU:
Hi All,

I am experiencing a similar issue to that noted by ozzyace.

My Logomatic was working well for several days of software development, but on the last attempt, the FW.SFE file was not flashed into the LPC2148. The processor does not appear to be running the application that was in it, prior to the failed load attempt.

I can still access the uSD card as a mass storage device, and have confirmed the formatting as FAT16.

I have tried to load the FW.SFE for my modified application, and when that did not work, I tried to load the FW.SFE from Sparkfun for the Logomatic - still no joy.

I don’t have a serial debug port connected, which is something I will have to try, to get some internal visibility on what is happening.

I don’t want to attempt to reflash the bootloader, if possible. Is there some internal vector table that may have been corrupted by an errant pointer in my code?

Any advice is appreciated.

Thanks in advance for your help,

shampoo:
This exact same thing is happening to me but on the Package Tracker. I guess I have bricked it ?

When I reset the the Package Tracker, nothing happens. If I plug it back into the Mac, the firmware is still there.

It did work for a few days and the upload, reset, boot loader sequence was fine. But then I started to get more and more problems. And now, nothing.

I’m suspecting hardware. I’m leery about getting another…

J

I’ve figured it out. In my case it was the SD card. The card was formatted FAT16 using Linux and also using Mac. This appears to have been the problem. Not all FAT16’s are created equal it appears. I have another FAT16 card that I used for another project using the Logomatic. When I copied the firmware to that, it works! Since both cards were 2GB, I just dd’d over the working one to the non working card and voila. It’s working fine.

The non-working card was formatted FAT16. I think it has to be formatted FAT16 in the same way the author of the boot loader expects. Again, my theory is that not all FAT16 formatters are created equal.

I hope this helps someone.

J

I found an SD card replacement fixed a different problem, also assumed to be hardware faults. I’d modifed a Logomatic V2 with a store of 1 farad per amp to maintain power while using a resistor and an LED to trigger shutdown when battery power was switched off. This was to protect the SD card, especially important if the battery fails during a write. I’d had trouble with it and spent a lot of time eliminating all possible errors in my hardware modification, and still the problem persisted, till I realised that the SD card might already be bad as I’d used it before I made the modification. it had worked originally, but ceased working after several uses in a Logomatic V2, so I strongly recommend my modification.

viewtopic.php?p=75458

I changed the SD card several months ago, and never seen any problem since.

One thing worth doing is to let an SD card fill up before you clear it. I don’t think they have wear levelling methods like those in CF cards, so the only sure way to prevent excessive wear on some of it is to let it all fill up before clearing it.