AVR CAN controller: what does this wierd phrasing in a datasheet note mean?

[HwAoRrDk]

I am presently writing some code that uses the CAN controller on an ATmega32M1. I want to put the CAN controller into standby mode whenever I put the micro as a whole to sleep, and put the CAN controller back to enabled when the micro resumes.

In the datasheet, I'm reading the documentation describing the CANGCON register that has the ENASTB flag. When describing putting the CAN controller into standby mode, it has the following note, but the language used there is very poor and makes no sense at all to me.

Note: A standby mode applied during a reception may corrupt the on-going reception or set the controller in a wrong state. The controller will restart correctly from this state if a software reset (SWRES) is applied. If no reset is considered, a possible solution is to wait for a lake of a receiver busy (RXBSY) before to enter in stand-by mode. The best solution is first to apply an abort request command (ABRQ) and then wait for the lake of the receiver busy (RXBSY) before to enter in stand-by mode. In any cases, this standby mode behavior has no effect on the CAN bus integrity.

What the hell do they mean by "wait for a lake"?! As a native Englishman, the word 'lake' has only one meaning to me: a large body of water entirely encompassed by land!

If I had to guess, I'd say the quoted excerpt above was written by a non-native English speaker, who may have had some native idiom in mind that didn't translate well. What could they have meant?

[sleemanj]

Maybe it is a bad translation of (does unicode work here yet...) 薮 which Google Translate isn't sure about in the Chinese->English direction but includes as noun "lake" and as verb "find, look for, search"

So, "wait for a lake" probably means "wait until you find "RXBSY".

Well that's my best guess.

[saike]

Looks to me like it should be  "wait for a lack of a receiver busy"

[HwAoRrDk]

Ah, yes, I think you're right! It hadn't occurred to me that they were going for a word that sounds similar.

Waiting for RXBSY to clear (i.e. 'lack' of flag being a zero) makes sense, and I was kinda coming to that conclusion myself after turning things over and over in my mind since yesterday.

[jnz]

Looks to me like it should be  "wait for a lack of a receiver busy"

Probably.

LOTS of CAN modules work like this. They can't actively switch modes while "the line is high" so you need to keep trying to set the mode in a loop or get creative when you know it's going to be recessive. Loop is the most common.

//set config
mode = normal;
while (mode!=normal);
//move along

The difference here is they are telling you a loop might need some extra conditions to get you out of it if you happen to enter at the wrong time.