I may have damaged my board, any advice?

[matt.stevenson]

I'm working with the RB-100, and as of yesterday everything was running fine. In fact I had just got my electronic compass working. I shut it down last night and went to bed.

Today I was busy building a box to mount the thing in. I finally went to turn it on and it is no longer recognizing the micro sd card.
I can get into bios, but there are no IDE drives detected.
If I let it boot, I just get an error and am asked to insert a boot device.

I tried booting from a usb drive with a bootable linux distro, but the board locks up after it initializes the USB drivers before it can get into bios settings.

I have no idea what could have happened to my roboard. It was working fine last night and today I had it out only to take measurements.

I've looked all over the board and I do not see marks, burns, or anything out of place.

I have a second micro sd card with ubuntu loaded, but I will have to do some digging to find it.

Any suggestions?

[PaulL]

Go back into BIOS and set your Primary IDE to Auto, save and exit, let me know if that works. If so, I will have more questions.

[matt.stevenson]

Wow, that was a lot easier than I thought things would be.
I switched to auto and I'm up running again.

Do you know what would have caused this?

[PaulL]

Well, I can tell you how I've done that to MY board. I was doing a lot of work on writing to PCI Configuration Registers, and a few times along the way, I ended up either locked up and had to reboot, or invoked a reboot inadvertently. In both cases, I would end up with the same message you got, and each time, I had to reset the hard drive back to Auto. Sometimes, I would be moving the mouse after having run some code, and it would lock while I was moving the mouse, for no apparent reason, with no code actively running.

What I think is happening is one of two things: Either some register code wrote to somewhere it shouldn't have, or there was a "collision" with accessing the PCI Configuration Registers, perhaps the O.S. was attempting to do something with the hard drive or something at the time. Changing things in the PCI Configuration registers the way that it's done in RoboIO and in the software I've written (they use the same method) isn't quite the right way to do so. If something else (the operating system) attempts to access the PCI Configuration Registers while your code is doing so directly, you have a crash, a conflict.

It's a problem because it's a two-step process, writing to the PCI Configuration registers. First, you put a value out onto the PCI Config Address Register CF8h, then you either read or write a value to the PCI Config Data register CFCh. I know in XP, you can be interrupted by the O.S., perhaps you write to CF8h, then the CPU writes to CF8h, then you write to CFCh, and then you have a problem.

As to why you didn't see it until a reboot, you won't see BIOS changes until you reboot / restart. What would be changing BIOS and why? I am not sure, but my only guess is that it's related to the PCI Config register access method.

Most (all?) of the setup options for Roboard's custom hardware is accessed via the PCI Config registers.

Registers that use PCI Config Registers include:

- Buffer Strength / Clock Output Control Register
- CPU ID Register
- CPU Revision Register
- Device ID / Vendor ID Register
- GPIO Port 0 / Port 1 Data Register Base Address
- GPIO Port 0 Interrupt Register
- GPIO Port 1 Interrupt Register
- GPIO Port 2 / Port 3 Data Register Base Address
- GPIO Port 4 Data Register / GPIO Base Address
- I2C Base Address
- Internal Peripheral Feature Control Register I
- Internal Peripheral Feature Control Register II
- Internal Peripheral Feature Control Register III
- On-Chip Device Control Register
- Servo Control Register
- SPI Base Address Register

That said, if you were doing work that included any of those registers, I think that may have caused the problem.

IF this is the problem (and I'm not 100% certain that it is), then the "true" solution is to have a REAL driver that works WITH the XP driver model instead of clobbering it. For XP, anyway.

What operating system were you using on your Roboard when it crashed? All will use the same PCI Configuration registers, and access to them depends on how the O.S. is built. Were you working with any of the above mentioned registers? If you're not sure, did you set some initialization for your compass? Which interface are you using to connect your compass?

Thanks,
Paul

[PaulL]

Another question - was your video card installed at the time you had the crash?

I'm running a test to see if anything changes the value of CF8 / CFC, going to beat the board up a little and see if it changes. If the values don't change, then I think it's a problem with some register write code.

Thanks,
Paul

[matt.stevenson]

I was doing some work on my board when I noticed, to my great surprise, a small amount of hot glue had dripped onto it. It was right on the edge of the bios battery. I have no idea how I managed to be so careless as to do that, but my workspace is very small and cramped. The glue was easy to remove.

My guess is that the hot glue was not hot enough to do any real damage to the board, but it was hot enough to drop the battery voltage and clear the bios.

Needless to say, I am feeling very stupid right now.

[matt.stevenson]

I reread your post, and the night before I was playing with the I2C and ADC for the first time. I had just got my compass working on the I2C (SCL and SDA pins only), but I had restarted the board several times while playing with it.

At the end of the night I was trying (unsuccessfully) to get a gyro working with the ADC. The ADC has to set the SPI clock on the I2C. I did restart once or twice while working with it, but maybe I did something there right before I went to bed. If it happens again next time I work with my gyro I'll know what to do, and I can let you know.

[PaulL]

Regarding hot glue, was that towards the back of the battery, towards the PCI slot? Mine came with a dab from the factory. I don't think it was the hot glue.

I have been beating things up a bit, and the CF8 / CFC values aren't changing from what I last wrote them to. I've exercised my code probably a hundred times in writing out all register values over and over, even let that run while I opened and saved files, etc. No lockups, none.

This gives me more confidence in using CFC / CF8. I wonder if I plug in a thumb drive what it will do. Just checked, nothing at all, that's what!

Still not clear on what caused this particular problem. I haven't seen any issues since I rewrote my code to use only 32 bit accesses to CFC / CF8 and pulled anything to do with the Flash SPI (prior to what I released here. ), so I'm thinking for me it was bad code, since CF8 / CFC have not changed on my Roboard with beating and banging on it.

I'm going to fiddle with the board some more and see if the PCI Config values ever change. If the values don't change, I would bet my issue was caused by bad code during testing.