It's a custom-designed PCB.

 

I can't even imagine how this is possible, let alone what might cause it.

The issue is outside of the transmission code.

It is simple to test: just stripe down the code to use the transmission code and you will see the correct data being transmitted. That means the issue is somewhere else in your code.

 

Thanks Dannyf but if you read back through the whole thread you'll see that I've already done that.

But given that the full original code runs on a revision 0x0 18F8722 but not on a revision 0x2 suggests that there are factors other than the code at play here.

 

Latest news:

I had a new 18F8722 fitted to one of the new boards, sourced through a different supply chain, just to make sure it wasn't a faulty/counterfeit batch causing the problem...unsurprisingly, it wasn't.

Still nothing from Microchip. Does anyone have any idea how long they usually take to reply to issues?

 

I'm not understanding this.

The hardware works under a simple transmission - you have shown that before.

The hardware doesn't work when the transmission code is integrated with the rest of your code.

Doesn't that suggest that the issue is with your code not the hardware? More specifically the issue is with your code other than the spi transmission piece.

Swapping out more mcus at this point doesn't sound like the most efficient approach to me.

 

I'm not understanding this.

The hardware works under a simple transmission - you have shown that before.

The hardware doesn't work when the transmission code is integrated with the rest of your code.

Doesn't that suggest that the issue is with your code not the hardware? More specifically the issue is with your code other than the spi transmission piece.

Swapping out more mcus at this point doesn't sound like the most efficient approach to me.

Or waiting for Microchip.

FYI, contact you local Microchip FAE. He, or an associated engineer, can stop by and maybe help you out.

 

I think your problem sounds like out of bound indexing, or an unitiated / run-amock pointer.

One way to identify the issue is to take out pieces of the code and see when the behavior restores.

Or to create a minimalist code that shows the problem.

 

I'm not understanding this.

The hardware works under a simple transmission - you have shown that before.

The hardware doesn't work when the transmission code is integrated with the rest of your code.

Doesn't that suggest that the issue is with your code not the hardware? More specifically the issue is with your code other than the spi transmission piece.

Swapping out more mcus at this point doesn't sound like the most efficient approach to me.

I understand what you are saying, and I agree that there is a "problem" with the code. But I have also demonstrated that the full complete code works on an old device and not a new one, so it is not "faulty" code as such but rather there has been some change in the device itself that has caused the code to stop working. Hence I was hoping that Microchip might be able to give me a clue as to what it might be...looks like that might have been a little over-optimistic!

 

I did some test with the pic18f8722 I/pt mask code 14364dg and made a coupling with mcp3551 and a display using SPI 1 for both.
No missing bytes bits of what so ever. Then I try to remove display pull-ups, fiddle around with enable timing this could as well know a lost of last or first byte.
However I was not able to emulate your problem.
Here are my settings.

/ -------------------spi bus master set-up ------------------
SSP1STAT= 0b1000000;
//**********************************************************************
// bit6 CKE=0; //0=Data transmitted on falling edge of SCK
// bit7 SMP=1; //1=SPI mode-Input data sample at end of data output time
//**********************************************************************

// SSP1CON1=0b00100001;
//bit 7 Wcol
//bit 6 slave mode overrun
//bit 5 SSpen 1 enable spi
//bit 4 ckp clock polarity
//bit 0-3 value
// SSPM=2; //FOSC/64
// SSPM=1; //FOSC/16
// SSPM=0; //FOSC/4
//************************************************************************
//--------------------------------------------------------------
SSP1CON1bits.CKP=0;

SSP1CON1bits.SSPM=1;
//------ enable the lot ----------------------------------------
SSP1CON1bits.SSPEN=1;
PIE1bits.SSP1IE=1;

//-------------------------------------------------------------------------

 

Thank you for your effort Picbuster, but am not in the least bit surprised that you can't recreate the problem.

If I isolate my SPI code from the rest and run it alone, it works fine. There's something elsewhere in the code that is causing it to fail when used on the newer device.

 

Could you show the code where you initialize SSP1CON1 and SSP1STAT? Are you changing these registers between bytes (or anywhere else)?

 

Thank you for your effort Picbuster, but am not in the least bit surprised that you can't recreate the problem.

If I isolate my SPI code from the rest and run it alone, it works fine. There's something elsewhere in the code that is causing it to fail when used on the newer device.

This is odd however next question: are many other interrupt running or a main loop faster than SPI byte timing.
Interrupt priority?
I was able to create problems in an interrupt doing. (indicating that interrupts could cause problems in other mechanism)
if (RC1IF) //RX int GPS data
{
RC1IF=0;
Gpsi=RCREG1;
putch(Gpsi); // to port2 output corrupted & bytes missing

May be a link to your problem

 

That's a reasonable thought, and one that was brought up before.

It felt like a promising lead, so I tried putting INTCONbits.GIE = 0 at the beginning of my SPI code and INTCONbits.GIE = 1 at the end, which should disable interrupts for the duration of the transmission, but this didn't help.

 

That's a reasonable thought, and one that was brought up before.

It felt like a promising lead, so I tried putting INTCONbits.GIE = 0 at the beginning of my SPI code and INTCONbits.GIE = 1 at the end, which should disable interrupts for the duration of the transmission, but this didn't help.

Only one solution for now; lets go to the pub and get p.......
I will get the last grey cells out off my overworked, underpaid, miserable but beautiful head to think of the real reason why the bldy pic/spi taken us to the cleaners.

 

Please give me your #define list. A long time ago I changed the SPI enable making a # define error and did a accidental direct fiddle with the enable line. ( this popped into my mind by your remark that SPI isolated did work.)

 

Only one solution for now; lets go to the pub and get p.......

Sounds like a plan!

It was worth a look, but no problems with the #define statements. If there were, I'd have thought it would cause problems no matter which revision of chip I was using wouldn't it?

 

If there were, I'd have thought it would cause problems no matter which revision of chip I was using wouldn't it?

If you do something undocumented (e.g. altering SSP configuration while it is enabled), it may work in one silicon revision, and not the other.

If you make secret of your config settings and initialization code, there's much less chances someone can help you. It's much easier to look at your config than to ask questions, such as "do you have the WDT enabled?" etc.

 

It's not a secret, it's just almost impossible to show in any kind of concise manner.

The code is a sprawling mess, with configuration all over the place, defines that are never used, things commented out and then re-entered...it's not nice at all. Suffice to say, I didn't write it.

 

Suffice to say, I didn't write it.

I see. In most cases like this, it's faster to re-write it

 

Hmm, I'm not sure that's practical on a 23,000 line codebase!