Power needs to be cycled after Write Calibration #15
Comments
|
@dbogdan, any thoughts on this? Should I wait for this to be fixed or reload both of these Rev F M1K boards I have been testing with v 2.09 as a fall back. ( the last version that seemed to work the best ). Thanks Doug |
|
Unfortunately, we didn't find what can cause this behavior. The new coefficients seem to be correctly stored even without cycling the power. |
|
Sounds like we just need to dig deeper/longer. |
|
I think I'm seeing that the channel B current settings are not actually
making it in correctly. Other wise I would not have been so totally
confused and posted issue #111 in libsmu ( now closed because it was the
firmware that messed up channel B ).
Doug
…On 1/15/2018 3:08 PM, Dragos Bogdan wrote:
Unfortunately, we didn't find what can cause this behavior. The new
coefficients seem to be correctly stored even without cycling the power.
By the way, did you see any other issues with v2.16?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALIL6qX4xP58uuFLd2GYTWlYQ5ink1v7ks5tK7BGgaJpZM4RdZFD>.
|
|
I'm still testing things. I'll get back to you is I find anything.
Doug
…On 1/15/2018 3:08 PM, Dragos Bogdan wrote:
Unfortunately, we didn't find what can cause this behavior. The new
coefficients seem to be correctly stored even without cycling the power.
By the way, did you see any other issues with v2.16?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALIL6qX4xP58uuFLd2GYTWlYQ5ink1v7ks5tK7BGgaJpZM4RdZFD>.
|
|
Just trying to be helpful here but it would seem to me that you could narrow things down a lot by comparing what you changed between 2.15 (works) and 2.16 (don't work). Could not have been very many things that were effected or am I wrong. Doug |
|
Hmmm... if I remember correctly, we've seen a different behavior starting with 2.14... |
|
I might be mistaken but I think I just tested a board ( HW Rev E ) newly
loaded with 2.15 and loaded an existing set of cal values from a file
and the board functioned properly without cycling power. I could re-do
the test.
Doug
…On 1/16/2018 11:31 AM, Dragos Bogdan wrote:
Hmmm... if I remember correctly, we've seen a different behavior
starting with 2.14...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALIL6vLzTOkeSRbnXdWGBpYd7HafGzYsks5tLM75gaJpZM4RdZFD>.
|
|
I tested the following version of the firmware to see at what point the write to calibration settings broke. So my suggestion still might be helpful if you undo the changes one at a time between working and not working version you might find what was done to cause the break? I'm a little disappointed that this problem was left in with out being notified that an issue existed for so long. It caused me much confusion. Doug |
|
Sorry to hear that, Doug. We discovered the issue only recently too, but we checked all the new versions to find the cause. |
|
I think that was an incorrect assumption and trade-off. There are
thousands of the original boards out there that were never "factory"
calibrated and there are more than 1000 of the originals still in stock
to be sold before any of the new ones hit the market.
And if a users ever loads new firmware the calibration settings get
reset, Am I still correct in assuming that when we do go to "factory"
calibration or will the factory setting be in protected memory that is
not wiped when new firmware is loaded?
If you can't make it work in the "released" firmware then turn that
feature off?
Not sure what to tell Users who need to re-calibrate after a firmware
up-grade.
Doug
…On 1/18/2018 10:07 AM, Dragos Bogdan wrote:
Sorry to hear that, Doug. We discovered the issue only recently too,
but we checked all the new versions to find the cause.
In order to be able to add support for newer hardware revisions, we
had to optimize more the timer interrupt handler - it seems that this
was the point where this strange behavior appeared. Since we thought
that the calibration will not be done too often (for many users
probably never - if the board comes calibrated from factory), we
decided that this is not something critical.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALIL6h2DNcj_9oLh8A64dEYRayk1IRPHks5tL140gaJpZM4RdZFD>.
|
|
libsmu should (I guess that it already does this) take care of saving and restoring the calibration coefficients when a firmware upgrade is done using the library. Unfortunately, that memory can't be protected. |
|
@dbogdan : "For the moment"; means we acknowledge it's a bug, and we are working on solving it? Or that is the permanent solution? |
|
libsmu should (I guess that it already does this)
Not the pysmu functions that I've been using. Not sure how the library
would do this. As far as I can see the power needs to be cycled after
loading the new firmware for Windows at least to recognize the change.
take care of saving and restoring the calibration coefficients when a
firmware upgrade is done using the library. Unfortunately, that memory
can't be protected.
For the moment, every user should unplug/plug the board after a new
calibration is done.
This does not solve the issue. If a board has been previously calibrated
the setting must be returned to the default settings in order to measure
the actual errors. Thus for the calibration procedure in ALICE the power
would need to be cycled TWICE. Once after loading default setting file
i.e before measuring the actual errors. and a second time after the new
calibration setting file is sent to the board.
This fact was what had me so confused. I had no way of knowing that the
act of writing the default calibration setting file did not leave the
board in a usable state.
|
|
Certainly, we don't want this to be a permanent solution: we will still investigate what can be done. |
|
Has this issue been resolved in the version released today? |
After writing new calibration values to the board, the outputs of the AWG are all messed up and you need to cycle power to the board to get it working again. After cycling the power, the board seems to be properly calibrated.
The text was updated successfully, but these errors were encountered: