Good thinking, but sadly doesn't help.

 

Good thinking, but sadly doesn't help.

Nothing changed? The waveforms are exactly the same as your prior photos?

 

Correct, no change at all. Even the second and subsequent bytes having their first bit and first clock pulse coincident is still present, although I don't see that using the "minimalist" code.

 

Correct, no change at all. Even the second and subsequent bytes having their first bit and first clock pulse coincident is still present, although I don't see that using the "minimalist" code.

Ok. Then I have no clue, save that the problem is definitely code, not hardware.

 

I took some pictures of the scope screen, capturing each byte as it is transmitted.

Byte 1 (SSP1CON1=0x22, SSP1STAT=0x40, data=0x00) seems to me to be fine, with the data line (upper trace) asserted, then the clock (lower trace) shifting each bit out.

Byte 2 (SSP1CON1=0x22, SSP1STAT=0x40, data=0x20) on first look seems good too, but I now notice that the data line and first clock pulse are co-incident, which doesn't seem quite right.

Byte 3 (SSP1CON1=0x32, SSP1STAT=0x00, data=0x08) also has this data/clock co-incidence problem, along with the obvious 7-bit byte issue.

View attachment 96567 View attachment 96568 View attachment 96569

It looks like your test code sends 55h and AAh. What happens when you send the exact same data that you observe the fail with?

Also, I didn't notice before but you report SSP1CON1= 22h then 32h means that CKP has been changed between bytes from clock idle low to clock idle high. That could explain a lot.

 

Doesn't matter what the data sent is, I've tried it with all sorts.

The change in CKP is intentional, but even if I keep it the same it doesn't work.

 

What happens when you just
1) Init the SPI and leave it alone
2) Use the low level write I posted here. That was lifted directly from an old 6722 project.
3) Don't change CKP or disable the MSSP at any time.
?

 

All,

Thanks so much for your help so far, I thought I'd let you know that I'm off until the New Year now. If you're still around then, I'd appreciate your further assistance. Until then, have a great Christmas!

Regards,
dK

 

Thanks so much for your help so far, I thought I'd let you know that I'm off until the New Year now....

Ha! So much for work ethic. I've done my best work during the holidays when everyone else was absent.

Merry Christmas.

 

Ha! So much for work ethic. I've done my best work during the holidays when everyone else was absent.

Merry Christmas.

+1!

 

Note to self: ask people if they can wait till after the holidays for an answer to their question(s). Merry Christmas and Happy New Year everyone.

 

Right, I'm back on this now. Hope everyone had a good Christmas and a happy New Year!

An interesting development: I have managed to acquire some "old" PCBs (manufactured originally, not from the new batch I've had done). I've programmed a couple with the test firmware and it runs perfectly...it doesn't perform the required overall function (this could be for any number of external reasons), but it does run without hanging.

MPLAB complains that the Device ID on the "old" devices is 000000 while that on the "new" ones is 000002. Could this be the reason that it doesn't run on the "new", but does on the "old"?

 

Device ID of zero could mean that the programmer has no idea how to get the device ID or does not recognize it. I would be careful about jumping to conclusions. At this point a MIcrochip FAE might be helpful if you can get his attention.

 

Right, I'm back on this now. Hope everyone had a good Christmas and a happy New Year!

An interesting development: I have managed to acquire some "old" PCBs (manufactured originally, not from the new batch I've had done). I've programmed a couple with the test firmware and it runs perfectly...it doesn't perform the required overall function (this could be for any number of external reasons), but it does run without hanging.

MPLAB complains that the Device ID on the "old" devices is 000000 while that on the "new" ones is 000002. Could this be the reason that it doesn't run on the "new", but does on the "old"?

Basically it means the programmer can't "talk" to the deice. This can be caused by issues with MCLR, OCG and a number of other reasons.

 

At this point a MIcrochip FAE might be helpful if you can get his attention.

Sorry, what is an FAE?

 

I've raised a "case" with Microchip via their online tool...let's see what happens!

 

Have you tried sending just two bytes or four bytes? If so, is the last incomplete as well?

I recall 7 bits xmitted instead of 8. Suggest a search in the Microchip forum or asking there.

 

Sorry, what is an FAE?

FAE = Field Application Engineer
They are like Circuit Judges and they visit distributors on a regular basis to help customer's with their application problems.

 

Curiouser and curiouser...

I've had a uC from one of my new boards swapped with one of the old ones...and guess what?

The new board that wouldn't run the firmware now does, and the old board that did run it now doesn't!

That suggests to me that either there is an issue on the new revision uC that the firmware doesn't account for, or the uCs on the new boards are all faulty.

Still no word from Microchip themselves on the issue that I raised.

 

Curiouser and curiouser...

I've had a uC from one of my new boards swapped with one of the old ones...and guess what?

The new board that wouldn't run the firmware now does, and the old board that did run it now doesn't!

That suggests to me that either there is an issue on the new revision uC that the firmware doesn't account for, or the uCs on the new boards are all faulty.

Still no word from Microchip themselves on the issue that I raised.

just to get my picture complete : what type of board are you using?
I never had any problems with pic 18f8722 using them for years in all type of SPI and other serial com things.
However; I did had some war with int1. It looks like interferes with the other RB port.( to lazy to solve. I used an other int.)