RS485: 9th Bit Protocol Implementation

[richard_bair]

I'm using a MCF52259 and trying to implement a 9th bit protocol where there are broadcast messages (mark parity) where all units on the network process the message and then are unit specific messages (space parity).  I've done this on an 8051 but never on a ColdFire and am struggling a bit

The master is this case is a PC based application that can send in mark/space parity.  What I envision follows:

1) On a point to point network (PC and Product w/ ColdFire), a mark/broadcast command is sent which sets a serial number for the product.

2) Product w/ ColdFire is added to a network of units.

3) PC test applicaton sends a mark/broadcast command processed by all units w/ ColdFires on the network which already went through steps 1 and 2.  This command includes the serial number and a working network address.  The unit that matches the serial number accepts the working network address.

4) The PC test application then can can talk to ALL units on the network and send various commands by bursting the working, network address in mark parity (broadcast) two times.  The unit that matches the working, network address simply sets it parity to space parity.  The PC test application will of course send the unit specific command in space parity.  Ideally, this is only "heard" by the unit with the correct working, network address.

So, I've got this coded up but it doesn't seem to work reliabily.  What I've noticed is that the ISR seems to process regardless of parity?  Does this sound correct?  I've read a bit about multidrop mode but can't find any examples and it sounds like the ADRESS mode (PM=11 and PT=0) may not be allowed to send multiple bytes as in my broadcast messages above.

Any guidance, help or pointed to an app note would be much appreciated!

-Rich

[richard_bair]

This thread may be applicable: 

https://community.freescale.com/message/52884#52884

Basically, here's what I'm doing so far that doesn't work:

1) I setup the port and have mark parity set (011 for PM-PT).

2) In the ISR I receive mark messages from the PC application.  This seems to work ok.  I set the serial number ok and then set the working address.  Each of these commands sends a response back in space parity and the PC application is receiving that.

3) Here's where it appears to break.  Once the network address is set, I burst that twice before setting to space parity to receive the rest of the mesage.  I can tell by debug that when my mark burst is being sensed and then the rest of the message works.  So I ran a test to burst the *wrong* address twice at mark parity and debug shows that the embedded side did not process those and therefore should still be in mark parity mode BUT the isr still processes the space parity message.  That's my issue...why would a space parity message be "heard" by the ISR? 

This is where I think I need to incorporate multidrop mode but I'm not certain of just how to do that .  I think the PC side using mark/space could transfer over to the ColdFire's multidrop address/data respectively.  I tried replacing all of my code where I set to mark parity to 111 for PM-PT.  For space parity I changed to 110 for PM-PT.  This started causing resets.

The thread above makes me think that multidrop mode must also work with the recevier state which I haven't changed.  It's basically alwasy enabled.

Thoughts?