-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modify serial nc tests init part #1781
Conversation
@mbed-bot: TEST HOST_OSES=ALL |
[Build ${MBED_BUILD_ID}] |
@mbed-bot: TEST HOST_OSES=ALL |
[Build 403] |
Based on the test results (even though they say failed, those are older issues), this doesn't look it causes regressions in other platforms. LGTM |
Hello @bridadan , |
Hi @adustm, I missed that the first time, thanks for pointing it out! That change is actually fine because that is not the behavior being tested. |
Hi |
I have shared a proposal here but I have not proposed it for pull request yet ... let me know if you think useful or not ... depending on what you say, this would require a wider testing (so far I tested on NUCLEO_F303RE and NUCLEO_F446RE) |
I see what you're doing, though I'm not sure that I immediately see the benefit. The Can I ask what motivated this change? Are you seeing any improvements on your end? In the meantime I'll run a bigger test to see what changes it has. |
@mbed-bot: TEST HOST_OSES=ALL |
[Build 407] |
@bridadan Sorry if not clear. I am proposing to add again a "getc while TX is at NC state" as suggested by adustm. Indeed, up to now target was calling MBED_HOSTTEST_START and just after that it was reconfiguring the serial link to "tx not connected + rx" - this was a raise condition to me because we're not sure whether the character from HOST would be sent before or after the new serial instance on TARGET will be created. Therefore, the character might be missed. Maybe the thing is that I am not clear of the complete path on how SerialNCRXTest wlll be called. Maybe a simple "time.sleep(0.5)" on HOST would be enough to ensure we leave enough time to target to delete serial instance and create new one ... |
Ah I see what you're saying, thanks for clarifying! It looks like this change has caused a regression in the NUCLEO_L053R8, I'll need to do a little bit more testing. I haven't seen any other platforms have regressions from this though. |
@bridadan What is the regression that you see on NUCLEO_L053R8 ? |
@bridadan : How have you noticed a L053R8 regression ? when I try to follow 'details' link above I get an ERR_CONNECTION_TIMED_OUT As far as I know the test result is mainly unstable so far ... so the possible errors you may see from time to time on NUCLEO boards shall anyway be fixed by another pull request: |
c = pc->getc(); | ||
// This should be false/not get here | ||
if (c == 'U') { | ||
pc->printf("RX OK - Unexpected\r\n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please fix the formatting. line 32, line 24 and 20 (tabs?) .
@0xc0170 I hopefully fixed the tabs issue in this new version (vim' expandtab option is definitely better than my hands made alignments ) |
During initialization phase of the 2 NC serial tests, there is a character being sent from host to target, based on MBED_HOSTTEST_START. The problem is that the target firmware then creates a "new" serial on the same serial interface. the new or should, or at least may, induce a reset of the IP, so that the character sent by host would be lost. So we're moving the new earlier. the real testing part happens later, to check the next character is not received or sent.
We're ensuring target and host start-up sync here in 2 ways: 1) adding a delay on host side to make sure the serial initialization can happen before sending a character is sent to target 2) in case of serial_nc_rx_auto.py test, we're sending a first character S which will trigger the move from rx+tx to NC+rx. This should avoid any crossing case due to HSOT being faster than target or vice-versa
@0xc0170 |
…..7963594 7963594 Merge branch 'release_internal' into release_external 9e31d11 Update apache license to config-files (ARMmbed#1781) b8f840c Merge branch 'release_internal' into release_external 9495d94 Rename cfg-files to h-files (ARMmbed#1780) git-subtree-dir: features/nanostack/sal-stack-nanostack git-subtree-split: 7963594
…..3abd82e 3abd82e Merge branch 'release_internal_v8.1.1' into release_external_v8.1.1 f2ca069 Update apache license to config-files (ARMmbed#1781) b2179ee Rename cfg-files to h-files (ARMmbed#1780) git-subtree-dir: features/nanostack/sal-stack-nanostack git-subtree-split: 3abd82e07a733fbb84e786f138541b5a0ef50c26
…..3abd82e 3abd82e Merge branch 'release_internal_v8.1.1' into release_external_v8.1.1 f2ca069 Update apache license to config-files (#1781) b2179ee Rename cfg-files to h-files (#1780) git-subtree-dir: features/nanostack/sal-stack-nanostack git-subtree-split: 3abd82e07a733fbb84e786f138541b5a0ef50c26
During initialization phase of the 2 NC serial tests,
there is a character being sent from host to target,
based on MBED_HOSTTEST_START. The problem is that
the target firmware then creates a "new" serial on the
same serial interface. the new or should, or at least may,
induce a reset of the IP, so that the character sent by host
would be lost. So we're moving the new earlier.
the real testing part happens later, to check the next
character is not received or sent.