Code hanging on getMagOnce()

[Deleted user]

@itkwon
My code works until it tries to run getMagOnce(). I think this is because the getStatusReg() function never returns the value it expects. Two questions:

1. Should the bitwise AND (&) be replaced with a compound bitwise AND (&=) when you check the register to see if it equals 0x02?

while((getStatusReg() & 0x02) != 0x02) --> while((getStatusReg() &= 0x02) != 0x02)

Also, I don't understand why you use a bitwise AND with the getStatusReg() function...

return getByte(0x8F) & 0x07;

[itkwon]

Hmm. I regret that my recent change might result in this bug. I cannot resolve this issue right now, but I will check with my chip as I go to the school tomorrow to figure out what is wrong.

1. Operator '&=' means 'getStatusReg() = getStatusReg() & 0x02'. It might accumulate the bug.

2. What I intended is to return only useful bits. Only three LSBs(least significant bits) are meaningful in 0x8F (Status Register).

I will modify the getStatusReg() return getByte(0x8F) temporarily. This is same as reverting my change.

3. If my library is fine without bug, there is a problem in your chip or your procedure of the code. I will check your code.

Thanks, and see you tomorrow.

[itkwon]

Also getMagOnce function is a wrapper function of getMagValue. getMagOnce waits the signal that AD5933 completes the ADC conversion. If you get the signal directly from getMagValue, the value might be incorrect.

[itkwon]

There are suggestion for your code.

1. [MOST IMPORTANT] getGainFactor() internally sets the status into "Standby" Mode. I think setting the status directly into "Repeat Frequency" mode might make problems. If you want to do this. I suggest to change the mode in sequence as described in datasheet. (Fig 28, Page 22/40)
   Standby -> Init_start_freq -> start_freq_sweep -> repeat_freq
   
   If you want to control the status register directly to operate AD5933, please be careful not to make any bug. I will test your code tomorrow. To see the example of using this library, please refer /AD5933_Test/AD5933_Test.ino
2. I suggest to execute AD5933.setExtClock(false) at the first time in setup().
   If you are going to use internal clock, use this function.
   I know that the default setting is using internal clock, but, because of the tendency of in-volatility of the register, I recommend to set it at the initial moment of executing the program.
3. Be sure to set all parameters and options before measuring any impedance.
   Please set increment, number of increment, Voltage & PGA Gain.
   If they are not done before frequency sweeping, I cannot guarantee that this library and chip operates successfully. I wasted around several hours with debugging before I realized this fact.

[itkwon]

I added below to try and yours works. (before REPEAT_FREQ)

AD5933.setCtrMode(INIT_START_FREQ);
AD5933.setCtrMode(START_FREQ_SWEEP);

I hope it helps.

[itkwon]

I am sorry. I think the verbose logging feature also contributes this bug. Thus, I will disable this before I debug the bug in the library. Other features other than logging are working clearly.
I also posted my suggestion with debugging. You can see that. Thanks.

[Deleted user]

@itkwon
Thanks for doing that! I'll see if my own verbose debugging feature causes the bug as well. I found a fresh ATMega32P processor to work with until I can flash the one that was unable to be programmed normally.

[Deleted user]

@itkwon
I went through my own copy of your library and deleted every line you wrote for LOGGING features, and it works! Your serial commands might have just been competing with mine to be output on the serial port. Good idea to check that!