So I was hoping that I wouldn't need help with this, but I do.

First, here is what the mod consists of. It is a rapid fire mod for Xbox 360 contollers. It has 6 different speed settings from 8 rps to 30 rps. It has an option of full auto, 3 round burst, or 5 round burst. Also, any of this can be applied to left trigger (LT) as well. So 6*3*2 makes for 36 possible configurations. And at any point, you can pause the mod and go back to normal mode.

This is all accomplished through an extra button attached to the back of the controller. Pressing it changes the speed from 0 - 7. Pressing it and RT changes through full auto, 3 round burst, and 5 round burst. Pressing the button with LT toggles left trigger on and off. And finally, holding the button for 1 second pauses the mod for normal use.


Ok, now the problem. Every thing was going great, I had gotten full auto working, then burst, and while I was working on adding extra button support, the chips became unresponsive. The chips still work when I put them in the controller, they do the last thing I told them to. But when I plug them into my computer, it can't read them or write to them.

At first I thought that maybe the chip had reached it max writes or something. So I pulled out a brand new one and tried it. It did just what I wanted it to. But when I tried to reprogram it, nothing.

I find it very unlikely that it fried or anything. The highest rating on one of the pins is 4mA. The only thing that seems likely is that some internal setting got changed. It stopped working shortly after I started using the internal timer, but I had still used it before.

And the specifics, the chip is a pic10f200. Here is the source if anyone wants to look. I guess all the problems started happening when the program flashed the LED for the first time. (It's flashed before, just not with this code.) So I guess that little section at the bottom of mainLoop might be the culprit. To kill it, you would follow, buttonPressed, and then it jumps back to mainLoop and dies.

Hopefully someone has an idea.
Fun stuff, thepenguin77; sounds like a very cool mod. I'll look through your code and see what I can find.

Some notes:
* "rlf speed, w ;clear carry" on line 62 - did you mean to rotate?
* I see no other particular flaw in your code; your flashing code seems legitimate enough. Sad
Oh, a few other things I should mention. The LT, RT, and LED are all turned on by sending ground. Sending positive will block them. But my switch that I added currently operates that ground is off, positive is on.

Edit:
I use rlf a few times later in the code to multiply by two. That step is just there to make sure that carry is cleared. Although I guess bcf status, c would work too.

If you see nothing wrong with the code then I am stuck again. I'll have to ask on one of the microcontroller websites but those get ~5 new topics per day, so it might not ever get answered.
Yeah, I don't see anything wrong. Sad Your flashing code in particular just grabs the sGpio, changes bit 1, and saves and outputs it. :/
Oh, dear. It would appear that the problem is not the code. I just took a brand new chip, my last as it would turn out. And I sent the program to it. Then when I tried to read it back, nothing. The chip is done after just receiving the program. That makes me feel that the protected program bit is set, although, I have no idea how to unset it.

Edit:
It doesn't look like code protection is the culprit. Protecting it leaves the first 64 bits intact and all the rest of the data reads as 0. Mine reads as 3FFF which is the equivalent of no chip attached.
Uhoh, that's no good. Do you think there's a possibility that either your programmer or your circuit is at fault? Did you test the chip before you put it in your circuit?
Order of steps.
1. Take PIC out of tube.
2. Place PIC in JDM programmer
3. Send program
4. Read back all 3FFF's
5. Fail to send any more data

This last chip didn't even see my bread board. It died immediately after programming. Although if I were to go test it, it would work perfectly.
thepenguin77 wrote:
Order of steps.
1. Take PIC out of tube.
2. Place PIC in JDM programmer
3. Send program
4. Read back all 3FFF's
5. Fail to send any more data

This last chip didn't even see my bread board. It died immediately after programming. Although if I were to go test it, it would work perfectly.
Wait, what? What do you mean it would work perfectly, if the programmer is reading that the entire contents of the chip are $3FFF?
Yes, it turns out that I haven't burned out any of my 10 chips, they have all just entered this state. As a microcontroller, they execute their code just fine. But they are completely unresponsive in my programmer.

What I mean by that is that if I took the microcontroller out of the programmer, ran downstairs, turned the xbox on, and tested it, I can say with certainty that the chip would make the gun fire rapidly.
That makes sense, but I'm mystified. I can only assume there's no way for you to troubleshoot your programmer or try to replace it (or try an alternate)? I assume you tried all the different kinds of things like restarting your programmer or reinstalling the drivers or something?
Well the programmer I use is very basic. Here is the same kind I got. Mine is slightly different, but this gives you an idea. This could be the problem, but I doubt it.

I just reinstalled winPic800, and it didn't make a difference.

Edit:
Cross posted on edaboard.com. Though don't post over there in that topic. I'll let them handle it in their normal way.
thepenguin77 wrote:
Well the programmer I use is very basic. Here is the same kind I got. Mine is slightly different, but this gives you an idea. This could be the problem, but I doubt it.

I just reinstalled winPic800, and it didn't make a difference.

Edit:
Cross posted on edaboard.com. Though don't post over there in that topic. I'll let them handle it in their normal way.
Aight, I look forward to seeing what they come up with about it, because I'm totally stumped. Smile
That programmer doesn't appear to have a power supply on it. How are you powering the programmer? PIC programmers generally put 13V on Vpp to put the chip into programming mode. RS-232 serial ports can supply around 12V normally which could be sufficient to enter programming mode, but a non-standard serial port (e.g. a USB adaptor) may only supply 5V and either not be able to program at all or program it incorrectly.

Of course, you may just be accidentally writing the wrong the configuration bits to the chip. Could you post your hex file?

A PICkit is definitely a worthwhile investment!
I run it from my computer's real serial port. I haven't checked the voltage lately, but I know it was in the 12V's. Would a slightly too low of voltage cause this problem.

I may have to get PICkit, that is what eveyone on edaboard said.

I was going to post the hex, but I think the latest post at edaboard hit it right on the nose. Since I have MCLR disabled, the chips can't be reset and are therefore locked. The JDM programmer just isn't complex enough to use the right algorithm to unlock them.
Ah, so what is the solution to the problem, then? Glad you're making strides, though.
The only solution to the problem that they gave me is to but PICkit. Using that, everything should work.
thepenguin77 wrote:
The only solution to the problem that they gave me is to but PICkit. Using that, everything should work.
That sucks. Sad I'm a bit confused as to why that's suddenly a problem though; hadn't you previously reprogrammed chips with no problems?
I'm not really sure why it suddenly popped up. I think it has something to do with the program being a certain size. I think I'm getting PICkit 2 as it seems better than 3.
thepenguin77 wrote:
I'm not really sure why it suddenly popped up. I think it has something to do with the program being a certain size. I think I'm getting PICkit 2 as it seems better than 3.
Oh, how so? Lack of testing and debugging made 3 buggier and less dependable than 2?
They took some features out and made it less reliable. For one, they took out the logic analyzer. If you go to the my edaboard post and watch the second youtube video the guy posted, you'll see what I mean. Plus, 2 is cheaper. Smile
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement