Accidently ran deck on MR16 in address mode, now can't program the start address

[charles59]

I had a MR16 that was working.
I used the address program, and set it channel 17.  All good.
Deck program demonstrated all was working fine.

Later, I reconnected (after chores, etc) to the MR16 again, and ran the Deck program.  I didn't realize, I had the address jumper on (I was going to readdress it, but forgot to do that).

Realizing my mistake, I reset everything.  and readdressed it to 1.
The deck seemed to work. 
However, now, I can not set the MR16 start channel with the address program.  No matter what I do.

I looked over the forum, and took the Pickit 2, and wrote the address to memory location 0a00.  That worked fine, and the MR16 now works on that address.
But every time I try the address program, it sets that memory location to 0.
I have reflashed the PIC, but same behavior.  I have downloaded the firmware from the wiki, same result.

Is there  a channel sequence that can damage the MR16?  It works fine, other then I now must use the Pickit to set the starting address.

[chrisatpsu]

i'd reprogram the pic, just to be safe

[charles59]

I did reprogram it.  

Still same result.  I can not set the address with the address utility, I have to use the Pickit to write to A00 what I want.

[RJ]

Interesting issue I have not seen. Can not understand why it would change as even if it where a bug reflashing the pic would put it all back to starting over. The system works very simply so you can even program it in Vixen by setting all channels to 0 except the first channel which you set to the channel you want it to be. Make sure vixen is in 0-255 mode instead of the 0%-100%. Try that and see if it works.

[charles59]

Yea, itis driving me crazy. After I accidently had the address jumper set with the deck, it wont take an address.

I reflash the pic (even clear it first). CHeck the checksum with that on the forum.

Put the address jumper on.
Start the MR16 address utility
pick my address I want.
start  programming.

Power up the MR16
Count to 5 slowly
power down the mr16 (even remove the power from the MR16 via disconnect of the cable).
stop the program
change the jumper off address mode (go to normal mode).
Try the deck.

It is still on address 1 (actually, reading the pic memory, a00 is now reading 0.

if I write an value to this location with the pickit, I can get the starting channel I want.

[RJ]

It must be a bad pic. That is the only guess I have with out any other input to point me otherwise. You are powering it from a power supply that is 7 volts or more correct. Under voltage can cause a pic to fail writing to the flash.

RJ

[Robert Waller]

Could be a bad pic but I don't know.  I'm working with Charles on this and after some additional testing, I'm now thinking that the initial sequence of events called out in his first post was not the issue.  At the time, we were unable to program the address and our only explanation was that the jumper setting had caused the issue.   I no longer believe that this is our issue.   

I think we are experiencing some overall inconsistencies with our MR16 addressing and we did not run the change address process enough times to get the address to change.  It could be we are doing something wrong so I am going to provide as much additional information as I can with the hope that you can point us in the right direction.   With that goal, I ran the following tests tonight.


Test Background and Scenario: 

I used five 18F1220 Pics for this test.  I labeled them A, B, 1, 2, & 3. 
I also ran these tests using two different MR16 boards that I labeled A & B.   As a note, both MR16 boards appear to work fine in operational mode.

I ran through the following sequence.

1. Initialize pics using the latest posted MR16 code (checksum 90D4) 

2. Ensure jumper on MR16 is in program address mode
3. Start MR16 address utility
4. Change address to 33 (0x21)
5. Start programming using address utility

6. Power up MR16 using 12v regulated power supply
7. Wait 5 seconds
8. Disconnect power to MR16 by pulling +12V lead

9. Remove pic and check address A00 for a change in value to 0x21
10.  When address changes to 0x21, set aside pic and continue process of changing address of other pics
11.  If address changes to 0x00, reinitialize pic, and put it back into queue for the next attempt
12.  Run loop until all pics change to address 0x21.

I ran this sequence with all five pics and Board A.  I then repeated the sequence with all five pics and Board B.  At that point, I decided to re-run the test again using Board A to look for any patterns.

Here are my results:

MR16 Board A  (first time thru)

   1st try:    pic 1, 3 changed to 0x21
                  pic 2, A, B changed to 0x00

   2nd try:   pic B changed to 0x21
                  pic A, 2 changed to 0x00

   3rd try:   pic A changed to 0x21
                  pic 2 changed to 0x00

  4th try:   pic 2 changed to 0x21


MR16 Board B

   1st try:  all pics changed to 0x00

   2nd try: pic 2 changed to 0x21
                pic 1, 3, A, B changed to 0x00

   3rd try:  pic B, 1, 3 changed to 0x21
                 pic A changed to 0x00

   4th try:  pic A changed to 0x00

   5th try:  pic A changed to 0x00

   6th try:  pic A changed to 0x21

 
MR16 Board A (second time thru)

   1st try:  all pics changed to 0x00

   2nd try:  pic 1, 2 changed to 0x21
                 pic 3, A, B changed to 0x00

   3rd try:  pic 3, A, B changed to 0x00

   4th try:  pic A, B changed to 0x21
                 pic 3 changed to 0x00

   5th try:  pic 3 changed to 0x00

   6th try:  pic 3 changed to 0x21


I used a PICkit 2 to re-initialize the code each time the address was set to 0x00.  Each time that I reinitialized a pic,  I also verified that the address value at A00 was reset to 0x01.  As a note, the PICkit 2 never failed to reset the address value to 0x01.

I also want to be clear that this does not effect the operational mode of the MR16.  Both of the MR16 boards appear to work fine using the deck program.


Any additional insight would be appreciated.   I wondered if the issue might be with the upstream dongle but I ran the test with a different dongle with similar results.