-
Notifications
You must be signed in to change notification settings - Fork 3k
ble: update ODIN drivers to v3.5.0 RC1 #8452
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
ble: update ODIN drivers to v3.5.0 RC1 #8452
Conversation
The failed ble example build error seen in the logs has now been fixed. We are also currently running the commissioning demo with this new driver. |
@paul-szczepanek-arm you are talking about BLE_GAP example right? |
@aqib-ublox There are errors in the greentea logs? |
@ARMmbed/team-st-mcd Could y'all take a quick look at the target changes? |
@cmonr can u point out which logs particularly by name? |
yes |
@paul-szczepanek-arm Yes after your recent commit few minutes ago ARMmbed/mbed-os-example-ble@68afa73 now I am getting BLE_GAP test also building. Thanks @paul-szczepanek-arm |
Only took a quick look at the following:
Scrolled all the way down, each file had at least one error. |
@paul-szczepanek-arm GAP example working fine arm_ble_GAP_log.txt this support your verdict. Thanks
|
@cmonr yeah but these errors is not specific to hardware like threads, mail or hci_transport etc. Am i right? |
@cmonr gcc_mbed-os_log.txt updated now all files having single ERROR in hci_test recently commited by ARM against cordio. |
@aqib-ublox Thanks for the update. |
@aqib-ublox Thanks for the update. From what I can tell, there are still the following issue with the logs:
Would it be possible to rerun the tests with |
#define ODIN_CORDIO_INTF_H | ||
|
||
#include <stdio.h> | ||
#include "mbed.h" |
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.
Can you include here files that are needed rather than mbed.h ?
|
||
/* if event is a command complete event */ | ||
if (*pMsg == HCI_CMD_CMPL_EVT) | ||
{ |
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.
should this file follow our coding style?
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.
@0xc0170 u r talking about putting baces on same line like:
if( xx ) {
}
I have tried following standard for var and functions naming etc. let me give second look to it .
ARM logs dont havé any issue with wifi test they are passing on ARM toolchain.
Please see log of mbed-os-tests-mbed_hal-sleep test for ARM and IAR toolchain.(they are passing)
mbed-os-tests-ble_test_case* are nothing but ARM BLE examples which are not made on green tea (ht-runner) framework, I added them for myself to generate binary in single compile command, this has nothing to do with mbed provided test sorry for incovenience. (Actually it needs to be ignore Right?)
they are also passing for ARM toolchain please see log.
I have increased this test time but still timeout let me re-evaluate it. (let me run it again with verbose on)
|
Dear @cmonr
I don't see any ST impacted file, this are only ublox and ble files. Kind regards |
@0xc0170 commit compliant with ARM coding standard is committed, I have delpoy changes bare-minimum according to standard adopted in ARM own cordio Class. |
Now it start passing just increase a time form 15 to 30 and it is running fine. please see logs |
@adustm Sure thing. |
@0xc0170 ok let me add commit right now and when changes finalized would reset commit history ,rebase and combine all changes with single commit and push, is it fine too? |
@paul-szczepanek-arm @0xc0170 Any more thoughts? Would anyone else from @ARMmbed/team-ublox like to review? |
|
||
void ble::vendor::odin_w2::HCIDriver::do_terminate() | ||
{ | ||
// TODO: ASRI |
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.
left over todo, implement or remove and track in jira
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.
that's oudated it is removed in latest commit
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.
actually we have not found any method in Cordio Transport driver which should update HCI baudrate at run time if needed, it assumes baudrate being set at initialization never changes so it was just done in that perspective e.g if we really need to change baudrate first we would terminate current session of HCI and then update baudrate and re-open it but it is not required so I removed TODO in last commit, hope it have clear idea?
shutdown = 0; // BT Power is OFF | ||
wait_ms(20); | ||
shutdown = 1; // BT Power is ON | ||
wait_ms(500); |
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.
why such a long wait?
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.
This is according to requirement of device power cycle
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.
But i thing BLE power up time is quite satisfactory now, isn't it?
Waiting for @ARMmbed/mbed-os-pan approval |
do you need this to go in today or is tomorrow morning OK? |
please ignore, that was a problem with my setup |
|
@paul-szczepanek-arm take your time but make sure that we will be able to pass this updated driver in the up-coming release. |
I'm almost done, investigating possible occasional missing scan timeout event. Is this something you've seen @aqib-ublox? possibly triggered by cancelling scan before timeout by calling stopscan (debugging atm), this is reproducible but right now I cannot tell if it's the driver's fault |
@paul-szczepanek-arm no till now i have not investigated this use case please share your finding and case study so that i can check if it is reproducible at my end as well? |
Until I narrow down the problem you can just try to repro it yourself. Start passive scan with some device advertising so that you get some reports but don't let it timeout and cancel it after 200 ms. Repeat a few times and it should fail. |
This is most likely not caused by the driver. I will follow up this issue but I don't think it should stop this merge. |
/morph build |
Build : SUCCESSBuild number : 3477 Triggering tests/morph test |
Test : SUCCESSBuild number : 3266 |
Exporter Build : SUCCESSBuild number : 3098 |
/morph mbed2-build |
Description
This Pull Request contains following feature:
Test Results
The following tests have been performed
arm_mbed_os_logs.txt
iar_mbed-os_log.txt
gcc_mbed-os_log.txt
iar_ble_logs.txt
arm_ble_logs.txt
gcc_ble_test_logs.txt
Pull request type