NEW! Uprising Control Series (Logic and Driver Boards)

[DJBecker]

The worst debugging problem I've had after replacing LQFP chips is some pins not making contact. You can almost always spot misalignment and solder bridges. But if you don't have exactly the same bump of old solder on the pads, some pins on the replacement chip can be held off the surface just enough to not join the solder pool. The pins might make contact only when cold, or only when you touch the chip.

I once spent a long day trying to figure what design or component problem caused my crystal to not oscillate unless I touched the chip. I was assuming that it was the added capacitive load from my fingers, when it was actually the pressure causing the pins to make contact with the board.

[adamj12b]

Well, Just a little update.

I have come back to this a few times getting frustrated each time...

I have found the problem, but according to datasheets, there is no problem...

The issue, I believe, has something to do with the watchdog shutting down the controller. Ive retested all hardware and everything is working perfectly.

If anybody feels up to it, the old processor was an Atmega644A and the new processor is the Atmega1284P. If anybody can find any differences, I would LOVE to hear about them.

-Adam

[dave koller]

Adam:
On the Atmega1284P does the watchdog stop the processor or does an event of lost oscillation stop it? I asked as DJBecker triggered a memory of a problem I had with a physical layout of the driving Xtal - I had to ground strap the metal can of it to stop an internal shutdown glitch due to stray spikes - I know - I know a stab in the dark ....

[adamj12b]

Originally Posted by dave koller

Adam:
On the Atmega1284P does the watchdog stop the processor or does an event of lost oscillation stop it? I asked as DJBecker triggered a memory of a problem I had with a physical layout of the driving Xtal - I had to ground strap the metal can of it to stop an internal shutdown glitch due to stray spikes - I know - I know a stab in the dark ....

Well It looks like the processor is still doing something because I still get a 16.0001Mhz clock on the CKOUT pin of the chip. If I enable the watchdog to always be on, the LED blinks rapidly and I get a clock out of about 2Mhz. This makes me think that when the watchdog is always on, the chip just cycles and cycles.

The way it is right now, the status LED is solid on.

Im going digging through the code again and going to try and set up some serial prints at points of start up hopefully to find where its failing.

On a side note, I commented out all the code in the enable and disable watchdog functions with no difference in operation..... This lead me to wanting to add the serial prints.

-Adam

[evimarn]

Originally Posted by adamj12b

Well It looks like the processor is still doing something because I still get a 16.0001Mhz clock on the CKOUT pin of the chip. If I enable the watchdog to always be on, the LED blinks rapidly and I get a clock out of about 2Mhz. This makes me think that when the watchdog is always on, the chip just cycles and cycles.

The way it is right now, the status LED is solid on.

Im going digging through the code again and going to try and set up some serial prints at points of start up hopefully to find where its failing.

On a side note, I commented out all the code in the enable and disable watchdog functions with no difference in operation..... This lead me to wanting to add the serial prints.

-Adam

Hi Adam,
I know it's a pain debugging such an issue and that you are really busy chasing 1001 other matters, this I ask as I am sure you have many of us on edge ,also how is the vette doing???

[adamj12b]

Originally Posted by evimarn

Hi Adam,
I know it's a pain debugging such an issue and that you are really busy chasing 1001 other matters, this I ask as I am sure you have many of us on edge ,also how is the vette doing???

I still haven't gotten the code to run on the new processor. Im sending it to a friend that is doing the code and hopefully with the controller in hand, he will be able to get it working...

The vette is coming along, but its slow. It all comes down to money. Currently I have enough to either, 1. finish the car's hardware and body work, or buy 1/3 of the batteries needed. The batteries are enough to make it move at 120V 80Ah, which would be about 20ish mile range, but then I will have to find money to finish the actual car...lol decisions decisions

-Adam

[evimarn]

Originally Posted by adamj12b

I still haven't gotten the code to run on the new processor. Im sending it to a friend that is doing the code and hopefully with the controller in hand, he will be able to get it working...

The vette is coming along, but its slow. It all comes down to money. Currently I have enough to either, 1. finish the car's hardware and body work, or buy 1/3 of the batteries needed. The batteries are enough to make it move at 120V 80Ah, which would be about 20ish mile range, but then I will have to find money to finish the actual car...lol decisions decisions

-Adam

I guess we're on the same boat the money saved always end up spent elsewhere.
Wish you luck and keep up the good work.

[electricstorm]

Adam,

What's the latest on your controller? Any progress?

Thanks,

Jim

[adamj12b]

Hello,

I have sent the board to a friend of mine to work on the software. I still have not gotten it to run the cougar firmware with the new 1284p processor, but its a SW issue and not hardware.

When Eric makes some progress, Im sure he will post about it here.

-Adam

[toddshotrods]

This is awesome! I am planning to build a Open Revolt controller for my hybrid hot rod. I have an 11" GE SepEx motor to drive the front wheels and the idea of using the AC setup to control the arm and field from the same controller is more than intriguing.

Will there be, or can there be, two control boards to enable individual and/or manual control of the arm and field separately?