There are a few different parts to your problem:
"Frozen" data registers
some data show up in these registers but after a certain point it is frozen
This is expected behaviour if you have read from any of the 6 data registers, but have not read from all 6 of them; or if you read from the Mode register and haven't written to it again. This is explained in the datasheet:
Data Output Register Operation
When one or more of the output registers are read, new data cannot be placed in any of the output data registers until all six data output registers are read. This requirement also impacts DRDY and RDY, which cannot be cleared until new data is placed in all the output registers.
You can detect this "Lock" condition when you read the Status Register - bit 1 (SR1) is set in that condition, as explained in the datasheet page in the Status Register (I have slightly edited this, to remove a typo in the original text, and to slightly improve the original formatting):
Data output register lock.
This bit is set when:
1. some but not all [...] of the six data output registers have been read,
2. Mode register has been read.
When this bit is set, the six data output registers are locked and any new data will not be placed in these register until one of these conditions are met:
1. all six bytes have been read,
2. the Mode register is changed,
3. the measurement configuration (CRA) is changed,
4. power is reset.
So your challenge is to debug your program, to find how you could cause that situation where you do not read all of the data registers, or where you read the Mode register and don't write it again.
Strange I2C command sequence in the datasheet
You said:
I suspect this part :
Send 0x3D 0x06 (Read all 6 bytes)
What does it mean exactly?
Good question. I haven't used that specific compass IC, but from I2C knowledge, that command makes no sense. 0x3D is the compass 8-bit I2C Read address, meaning that as soon as the I2C Slave device (i.e. here, the compass) ACKs its address, it has control of the bus - the I2C Master cannot send another byte (i.e. here, the 0x06) if the Master correctly follows the I2C specification.
I did a quick search and none of the code samples I found for this device, use that I2C sequence. At least one person claimed that attempting that command caused a hang - perhaps attempting this invalid I2C sequence caused the code running on their MCU master to hang.
See the next point for the suggested command sequence.
Other questions
Or we only need to provide the first register address and the I2C takes care of the next registers?
Almost - you do an I2C transaction to write the address of the first register you want to read. That is why you see the suggestion:
Send 0x3C 0x03
... before reading the 6 data registers.
Then this device implements auto-incrementing of the register address for the subsequent reads. This behaviour is optional in the I2C specification, so don't assume that "I2C takes care" of this on every device - read the device datasheet (and some sample code) to see the specifics. For example, this device's datasheet says:
To clock out the new data, send:
0x3D, and clock out DXRA, DXRB, DZRA, DZRB, DYRA, and DYRB located in registers 3 through 8. The HMC5883L will automatically re-point back to register 3 for the next 0x3D query. All six data registers must be read properly before new data can be placed in any of these data registers.
In my search, I didn't see any examples where the code relies on the claimed internal register pointer "re-pointing" back to register 3 mentioned in that part of the datasheet. I even found a note which explicitly says that such behaviour does not happen on the HMC5883L, although it did on the older HMC5843. Therefore I would not rely on this sentence in the datasheet. Instead I would repeat the "Send 0x3C 0x03" sequence before each "loop" of reading all 6 data registers, as shown in the "continuous measurement" example loop in the datasheet.
Is there an simplified example code?
I found lots of code examples in a quick search, mainly aimed at Arduino usage, but it's just I2C, so it can be ported to another platform, if needed.
One final point: It isn't clear if you are using a ready-made PCB module which you bought somewhere, or the PCB is your own design. Especially if this is your design, note that this type of device causes relatively large, short duration, power consumption spikes from its required capacitors (C1 and C2 in the datasheet schematic). Therefore the PCB layout and those capacitors are critical to reliable operation. Again, there is advice in the datasheet.
