cancel
Showing results for 
Search instead for 
Did you mean: 

I'm having trouble using multiprocessor communication.

MPere.2.287
Associate II

I'm involved in the developmentof a project where I will use STM MCU that has the capability of multiprocessor communication ("Multiprocessor communication").

This type of communication allows multiple USARTs to be connected on the same network and only the recipient actively receives the contents of the message, for this to occur it is necessary to store the address of this MCU in a register.

So far so good, if only one word of address is used.

But I have to use more than one word of address, in this case, so whoever receives a valid address does the exchange of the address

next expected address, ie I make a new store in the registered MCU.

Now the problem.

When I use the MCU STM32F407 with serial at 115200 bps and the MCU clock at 48MHz, I send a sequence with 4 words and everything works fine,

now I do the same test with the MCU STM32F303, the MCU can only identify the first word and the other 3 not, if you send each word

of the sequence with a delay of 43uS the entire sequence is fully recognized.

I send the following sequence with 9-bit words:

0x101 0x102 0x103 0x104

13 REPLIES 13

Hello Alex, I'll pass you a pdf in more detail than I'm doing.

Hello AvaTar, I'll pass you a pdf in more detail than I'm doing.

Thanks for the information.

It appears that you setup the STM32F303 with address ADD[3:0]=0001

According to the Figure 9 on your document, you are sending the following words:

0x101

0x102

0x103

0x104

All these words are addresses, as the most significant bit is 1. Therefore, the STM32F303 should only recognize the first word (0x101) as valid and should ignore the other 3.

There should be only 1 call to the Interrupt handler.

Now, your code appears to change the address during the interrupt, but it is not clear, as the WRITE_NIBBLE(flagAddress) macro is not provided. Is that correct?

If so, you would then expect 4 calls to the Interrupt Handler.

However, your code disables the USART to be able to write the new address, and then re-enable it (all inside the the Interrupt Handler). This might create unexpected behavior or delays in the USART hardware to be able to detect the next address word.

I would recommend changing your code to do the following:

  1. Do not disable/enable the USART inside the Interrupt Handler.
  2. Use a fixed Address (at least during the testing /development)
  3. Transmit the following data: 1 word with address information and then a few words with data information. That way you can see if both paths of the code are working.
  4. Use a fixed size packet (or a delimiter character) to determine the end of a packet and to enter Mute Mode again.

AvaTar
Lead

I never tried this "multiprocessor mode", but the UART basically transfers bytes only.

And if you do not pick up received bytes from the Rx register before the next byte arrives, you get an overflow. All reception then stops until you clear this flag. I think this is the same in multiprocessor mode.

Hardware flow control might help, but keeping interrupt routines short is essential.

Cube/HAL callbacks happen in interrupt context, and will block recurrent interrupts.