RS485 Communication- board Hangs
I suspect from your question that you kinda know the generic answer already :-) The work that your code has to do within a loop can reliably be finished in a second, but possibly not within 100 ms. At least that's an initial hypothesis worth testing.
288 bits equals 36 Bytes, right? At 460800 bps you should be able to transfer 46 kB per second, or 4.6 kB per your shorter loop period. I.e. that alone wouldn't explain the hangs. The code running on the board that hangs may have other hard work to do, apart from transmitting, or can be waiting for the other RS485 node to respond, and the delays may sum up to the 100 ms period, and the software is written such that it is not tolerant to that situation... and it doesn't really matter if you get unhandled interrupts or just sloppy code running at the basic (foreground) &quot;scheduling level&quot;. If the board doesn't hang immediately, but it takes some random time, perhaps there are other tasks / IRQ service routines interfering, which randomly prolong the duration of your foreground activity, or something. The possibilities are infinite. Hard to say where the bug is in code that we haven't even seen.
Obviously the devil's in the details, and you have not provided any.
If you'd like to start debugging from the communication patterns and periodic turnarounds, I suggest that you get an oscilloscope or a logic analyzer or a PC with a serial port and timestamped capture capability (ExtraPutty?) or even just a notebook with modern HDA audio input, and try recording the communications pattern paced at 1 s first, to see how long it actually takes to complete every cycle. To find your problem, you need to measure, somehow. Improvised probes are not outlawed, as long as they get the job done. If you try to use an audio input, be careful not to nuke it with over-voltage = pay attention to signal levels and earth isolation where appropriate.