Infineon C167 CAN通信发送ulong类型变量时原子性违规（atomicity violation）导致数据跳变求助

Hey there, let's dig into this CAN communication glitch you're hitting with your Infineon C167CS (ST10F168) when sending ulong variables. Those random data jumps you're seeing are almost definitely tied to atomicity violations—here's why that's happening and how to fix it:

The Root Cause #

Your C167 is a 16-bit microcontroller, right? A ulong is a 32-bit value, which means reading or writing it requires two separate 16-bit operations. If something (like an interrupt that updates your ulong variable) interrupts that two-step process mid-way, you'll end up capturing a half-updated value. When you split that broken 32-bit number into bytes/words for the CAN frame, the high and low halves won't match, causing those weird jumps in your captured CAN data.

Fixes & Debug Steps to Try #

• Protect the variable read with a critical section
  This is the most important fix. You need to make sure reading the 32-bit ulong happens in one uninterrupted step. On the C167, you can disable interrupts temporarily to create a critical section, copy the variable to a temporary buffer, then re-enable interrupts before packing it into the CAN frame. Here's a quick code example:

  // Your original 32-bit variable that might be updated by interrupts
  ulong my_ulong_data;
  ulong temp_buffer;
  
  // Enter critical section: block interrupts
  DI(); // C167 instruction to disable interrupts
  temp_buffer = my_ulong_data;
  EI(); // Re-enable interrupts
  
  // Split the atomic buffer into 16-bit words for CAN transmission
  uint16_t low_word = (uint16_t)(temp_buffer & 0xFFFF);
  uint16_t high_word = (uint16_t)((temp_buffer >> 16) & 0xFFFF);
  
  // Pack low_word and high_word into your CAN data frame and send
  

  By using the temporary buffer, you guarantee you're sending a complete, consistent snapshot of my_ulong_data.

• Double-check where your ulong variable is being updated
  If my_ulong_data gets modified in an interrupt service routine (ISR)—say, a timer interrupt updating a counter—this is exactly where the atomicity conflict happens. The critical section above will block that ISR from running while you copy the variable, so you don't catch it mid-update.

• Verify your CAN frame packing logic
  Make sure you're splitting the temporary buffer (not the original variable) into bytes/words consistently. For example, if you send low byte first, stick to that order every time—but don't worry, byte order issues would cause consistent misinterpretation, not random jumps. The jumps are all about incomplete 32-bit reads.

• Debug to confirm the issue
  Use your CAN-USB tool to capture frames and compare the high and low 16-bit halves. If you see frames where one half is from an old value and the other is new, that's a dead giveaway that you're reading the 32-bit variable mid-update. You can also use your debugger to watch the temporary buffer vs. the original variable during transmission—you should see the temp buffer always has a full, consistent value.

Give these steps a shot, and if you run into snags with the critical section setup or need more specifics on the C167's CAN module, just holler.

内容来源于stack exchange