Sanitycheck fixes, enhancements #21684
Conversation
Some platforms use this USB device for serial, detect it when generating hardware map. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Instead of N/A, use Unknown which is more appropriate, N/A does not really apply here. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Fix issue where we timeout in handler and show the device.log file instead. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add some verbosity into the log file to help with debugging. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
|
All checks are passing now. Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages. |
scripts/sanitycheck
Outdated
| @@ -575,6 +576,9 @@ class BinaryHandler(Handler): | |||
| t.join() | |||
| proc.wait() | |||
| self.returncode = proc.returncode | |||
| (stdout, stderr) = proc.communicate(timeout=30) | |||
There was a problem hiding this comment.
_, stderr = proc.communicate(timeout=30)pylint would warn, but it's hidden due to stdout being set earlier.
There was a problem hiding this comment.
Oh... pylint did catch it.
nashif
force-pushed
the
sanitycheck_dec2019_enh
branch
from
3bf776f to
fd9d4c6
Compare
Reduce duplicated code by introducing a dedicated function for running custom scripts. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
More debug messages to help locate issues and debug bugs. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Make sure we close the pipe file handles after we are done, otherwise we will end up with too many open file descriptors and crash... Fixes zephyrproject-rtos#20974 Fixes zephyrproject-rtos#21637 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
nashif
force-pushed
the
sanitycheck_dec2019_enh
branch
from
fd9d4c6 to
2b8d5ba
Compare
Instead of failing, report overflow when the SRAM overflows. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
nashif
force-pushed
the
sanitycheck_dec2019_enh
branch
from
2b8d5ba to
a5e2a55
Compare
Support custom hooks after flashing is completed. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
There was a problem hiding this comment.
Now that feature is working. But need one change, pls see my review below.
P.S. That is good that now possible to use 3 additional scripts. Because we can turn on the board and put it into reset mode -pre_script, then after flashing put it into operating mode - post_flash_script, and then turn off the board -post_script.
| @@ -703,6 +719,7 @@ class DeviceHandler(Handler): | |||
| command = [get_generator()[0], "-C", self.build_dir, "flash"] | |||
|
|
|||
| while not self.device_is_available(self.instance.platform.name): | |||
| logger.debug("Waiting for device {} to become available".format(self.instance.platform.name)) | |||
There was a problem hiding this comment.
That print is going all the time when device is being programming. Like:
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
DEBUG - Waiting for device mec15xxevb_assy6853 to become available
For me that print caused misunderstanding if a device has a problem. Only when I commented it out, I realized that device is programming in the background and everything is ok. I think necessary to remove that print or change text. "Device programming. Soon it will be available" for example
There was a problem hiding this comment.
this is just a debug log message, it does not impact functionality. It means the device is locked and being used to run a test, so the next test can't execute yet. Useful for debugging possible lockups and races.
There was a problem hiding this comment.
"Device programming. Soon it will be available" for example
the message is not related to flashing at all, the device is just not available and anything might be going on, for example a test might be running.
There was a problem hiding this comment.
Ok, understand. But in my case that message is printing during the first flashing process. And then test start to execute. It means that message is printing while the flashing process is running, but after second flashing process that message is not visible.
Fixes #20974
Fixes #21637