1
\$\begingroup\$

I am trying to communicate between two STM32-based devices using infrared light. The first device is the official STM32L0538-DISCO development board, the second is a Chinese mini board based on the STM32F103C8T6; they are also called Blue Pill.

I use transmitters on TFDU6102, according to the schematic that is given in the datasheet as recommended (I made two small printed circuit boards / two modules).

At the moment, I just want to make a loop to send data from one device to another, receive this data, and return it back to the first. I tried different configuration options, different speeds and modes of operation of the IrDA UART, but it never worked.

This is how I send data from one board to Bluepill:

HAL_IRDA_Transmit(&hirda2, (uint8_t *)"Hello, world!\r\n", 15U, 250U);

But there is a problem with getting data, I call it before the main while loop:

HAL_IRDA_Receive_IT(&hirda2, receiveBuffer, 1U);

And I also have a method to handle the interrupt:

/* USER CODE BEGIN 4 */
void HAL_IRDA_RxCpltCallback(IRDA_HandleTypeDef *hirda)
{
    uint8_t recivedByte = receiveBuffer[0];
    receiveBuffer[0] = 0;
    //IrdaNetwork_ReciveByte(recivedByte, 0U);

    HAL_IRDA_Receive_IT(&hirda2, receiveBuffer, 1U);
}
/* USER CODE END 4 */

I post a bare CubeIDE project, where I just try to read byte by byte IrDA - BluePill_2.

  • The modules on the TFDU6102 are working, if you connect each one to the STM32L0538-DISCO, then they work correctly, both for reading and for writing.
  • Reading bytes, not through interrupts, on the Blue Pill also does not give results.
  • The interrupt for reading on the Blue Pill itself seems to work, if you shine with the remote control (I have it from a floor fan), then sometimes it happens that it reads something, some random byte. I understand that the remote is not IrDA, but just as a clue.
  • The transfer from Bluepill to another board via IrDA is correct and without errors. The problem is in reading.
  • Exchange just via UART works correctly.

In an attempt to find the problem, I decided that I needed to record the signal that comes from the RX leg - TFDU6102. I set up the TIM1 timer as in the screenshot: Timmer settings Clock settings This should enable me to record the entire transmission signal of my message. I have 15 characters, that's 120 bits + 30 bits for stop/start bits. At a speed of 115200, this is approximately 1.30208 ms. The timer counts down the period in 1.39 ms. I write a signal through interrupts with the following code:

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
    uint16_t currentCounter = __HAL_TIM_GetCounter(&htim1);
    pinTimeArray[pinArrayIndex] = currentCounter;
    pinArrayIndex++;
}

I get the following spacing values:

32816, 32876, 33128, 33188, 33441, 33501, 33752, 33812, 34377, 34437, 34688, 34748, 35312, 35372, 35937, 35997, 36560, 36620, 37184, 37244, 37496, 37556, 38432, 38492, 39057, 39117, 39368, 39428, 39680, 39740, 40616, 40676, 41552, 41612, 42176, 42236, 42488, 42548, 42800, 42860, 43736, 43796, 44672, 44732, 45298, 45358, 46856, 46916, 47792, 47852, 48417, 48477, 48728, 48788, 49040, 49100, 49976

I assume that the first element is a reference point and by calculations I get the following table with times (where the last column is the time of the bits if they were transmitted simply by uart): Times table

This is what the graph looks like, according to the last column. It seems to me that it fully complies with the IrDA protocol: Graphic We get the bits - 00010010, which corresponds to the letter H (although the order of the bits is inverted). After goes - 10100110, this is the letter e. The minimum pulse of a zero bit is 0.00166667. For a speed of 115200, where the time per bit would be 1/115200 * 1000 - 0.008680556 ms for a standard UART, and multiplied by 3/16 (for IrDA), we get 0.001627604 ms. So the timing is right too.

Please let me know what what am I doing wrong, or what feature am I not aware of? Thanks!

\$\endgroup\$
8
  • 1
    \$\begingroup\$ And another question, ... .... what is your first question? \$\endgroup\$
    – jsotola
    Dec 25, 2022 at 19:12
  • \$\begingroup\$ Most likely this is all a general question, the second one is specifically about ways to debug the error. \$\endgroup\$ Dec 25, 2022 at 19:54
  • \$\begingroup\$ you did not ask a first question \$\endgroup\$
    – jsotola
    Dec 25, 2022 at 20:58
  • 1
    \$\begingroup\$ Since IrDA is a function of USART module, try first a direct transfer between the two boards with the regualar UART mode. \$\endgroup\$
    – Flexz
    Dec 26, 2022 at 5:10
  • 1
    \$\begingroup\$ Direct connection would not work for IrDA, you'll need an inverter, see "IrDA data modulation" in the reference manual for mcu. \$\endgroup\$
    – Flexz
    Dec 27, 2022 at 5:10

1 Answer 1

1
\$\begingroup\$

Chinese versions STM32F103C8T6 do not support IrDA :(

After I didn't get an answer here, I asked on some local groups. I was informed that this is not the first time this has happened and we have come to the conclusion that my BluePill boards are fake. There is no direct confirmation of this, only the possibly low price of these boards - $2.5 with delivery to Russia. In appearance and markings this is an original STM32 board - the full marking of the chip is "STM32 F103C8T6 991KA 93 MYS 808".

\$\endgroup\$
1
  • \$\begingroup\$ Does this relate to the question? So it does not work because you thought you had a STM32 but it was a clone like GD32 instead? If so, can you expand the answer? \$\endgroup\$
    – Justme
    Sep 30, 2023 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.