bouffalo_sdk
bouffalo_sdk copied to clipboard
bouffalolab
SDK fixes for BL702 (EFUSE, USB, ADC, etc.)
Hello,
We have got lot of issues with recent bouffalo_sdk for BL702 MCU especially with EFUSE support, clocking, USB, ADC and compilation warnings. This issues were fixed and extensively tested on custom BL702 board and with XT-ZB1 evaluation board. Please, make review and pull changes to upstream SDK version (v2.0).
Thanks for you effort to point out sdk issues, i will spend sometime to check them and merge into our internal repo.If some commits can be cherry-picked, i will pick them, others will be modified by manual.
@mdednev
With your patch the basic blink example finally started to work for me on Sipeed M0Sense (BL702), so thank you very much :)
I hope that it will find a way to master one day...
@sakumisu Is there any specific reason why you won't provide us with ROM API documentation?
@iamdavidcz as far as I remember, all functions in ROM are also implemented in SDK.
@iamdavidcz as far as I remember, all functions in ROM are also implemented in SDK.
Yes, they are supposed to be implemented in SDK, but there is two questions:
- Is their SDK implementation the same as ROM one? And is it so tested and functions as ROM one?
- Should we spend user flash on SDK function implementation while this implementation is already in MCU ROM?
I think the answers are 'no' and 'no'. And at this time I've chosen ROM implementation.
With your patch the basic blink example finally started to work for me on Sipeed M0Sense (BL702), so thank you very much :) I hope that it will find a way to
masterone day...
I hope so, because I've got next patch set for BLE stack port integration from bl_io_sdk to new SDK 2.0, but it can't perform successfully without patches, provided in this PR. I've tested this port and it works seamlessly.
1, All the rom api has corresponding source code, we just disable some romapi and patch them in source code. 2, Some romapi has bugs, so if you use romapi, the result you should consider.
1, All the rom api has corresponding source code, we just disable some romapi and patch them in source code.
Do you have original ROM API source code to patch it and reimplement in SDK?
2, Some romapi has bugs, so if you use romapi, the result you should consider.
Could you provide some examples of such bugs? I want to try it with my firmware, based on ROM API.
Some changes i will pick and others need be modified correctly( these i will modify in sdk without picking your commits).
1, All the rom api has corresponding source code, we just disable some romapi and patch them in source code.
Do you have original ROM API source code to patch it and reimplement in SDK?
2, Some romapi has bugs, so if you use romapi, the result you should consider.
Could you provide some examples of such bugs? I want to try it with my firmware, based on ROM API.
1, You can search the same api in romapi.c and other file like bl702_glb.c, bl702_hbn.c and so on. 2, Other chips we provide romapi_patch.c with source code and disable them in romapi.c, for bl702 and bl602, you can see source code in other c files, follow 1.
These romapi patches have synced in iot sdk and bouffalo_sdk, so cannot enable some of them. This will cause different romapi versions.
@sakumisu can't be then this change applied only for BL70X?
Not work on bl702 also.
@sakumisu can't be then this change applied only for BL70X?
Not work on bl702 also.
I've checked this code and it works perfectly with unresponsive devices. In contrast original SDK driver hangs without timeout error.
NAK condition is one of the valid cases in I2C bus interaction, regarding to the I2C bus specification. So it should be explicitly handled in properly written driver.
@sakumisu can't be then this change applied only for BL70X?
Not work on bl702 also.
I've checked this code and it works perfectly with unresponsive devices. In contrast original SDK driver hangs without timeout error.
NAK condition is one of the valid cases in I2C bus interaction, regarding to the I2C bus specification. So it should be explicitly handled in properly written driver.
But we use three image sensor, all of them fail.
But we use three image sensor, all of them fail.
How it fails? Could you provide more information on this failures? Did you try to check, which added NAK condition check causes failure?
If you think it is ok, pick into your own repo.
Of course I can, but I want to get reliable I2C driver for all of us. :-)