FreeRTOS, queue byte alignment

[Harvey White]

For whatever reason, I'm getting byte alignment problems with queues. I have a 32 byte queue, and the last two bytes are now garbage (they weren't before). No system settings have been changed, and I'm using all the defaults. If I expand the size of the queue from 32 bytes to, say, 34 or 36 bytes, the garbage area moves down.

The data structure is a mixture of uint16_t and bytes. FreeRTOS queues take pointers to data structures.

I've had the same thing when writing the structure to an NRF24L01, having to reduce the active part of the packet by two bytes, which are then trashed with surprising regularity.

So the workaround is to write more data to the queues maintained by FreeRTOS, then use only the good part of it.

The problem with the NRF24L01 is "solved" by reducing the payload significant data from 32 bytes to 30 bytes, but still using a packet size of 32 bytes. It's not the chip, since data arrives (using shockburst) with the proper checksum, packet ack, and no errors on transmission.

Shockburst mode sends a packet to the receiver, performs a checksum, then sends an ACK/NACK back to the transmitter to validate reception. So a packet that's been acked has been received properly and validated at the other end. The packet at the other end had the garbage last two bytes, so that's the way the chip at the transmitter end got it.

Any comments?

Workaround are ok, but it might be nice to fix this properly.

[TDK]

Put a watchpoint on the problem bytes. Gotta be something that’s accessing them. Bytes in memory don’t change values on their own.

Could be that they’re wrong immediately, or never written to.

[Harvey White]

The bytes turn out to be "never written to". (default memory settings from FreeRTOS).

Looking at the raw memory dump, the bytes were not in byte order.

The pointer accessed things in a different order than the byte order, so I am guessing that the way that the bytes are accessed by a byte pointer and the way that the processor stores mixed byte and word (16 bit) data are different.

[Jack Peacock_2]

If you have a struct with unaligned members you need to add the .packed attribute (for GCC) to the structure instance. Otherwise the struct has pad bytes to align anything bigger than a byte. Check your struct with a sizeof() to see if it's exactly what you expect.

Jack Peacock

[Harvey White]

The fun part is that apparently .packed may not be supported depending on the compiler. I've had problems with sizeof() not working well. .packed came up in an internet search, along with several dozen opinions why it wasn't a good idea, and portability was only one.

More Fun. I'll give that a try, though.

[TDK]

> I've had problems with sizeof() not working well.

This is unlikely, unless you're using some home-brewed compiler. Maybe you were expecting a different value because of packing?

> The fun part is that apparently .packed may not be supported depending on the compiler.

In reality, all modern compilers support the ability to pack values, though the syntax varies. You need to have this if you're interfacing with other hardware.

You could also consider defining the structure as just a string of bytes (uint8_t) that you write different data into.