-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Cleanups #384
Cleanups #384
Conversation
This rework is done in order to prepare for propagating errors returned by libusb. Signed-off-by: Maxime Coquelin <[email protected]>
This rework is done in order to prepare for propagating errors returned by libusb. Signed-off-by: Maxime Coquelin <[email protected]>
_stlink_usb_target_voltage already returns an error value. If value return is positive, this is a voltage, if negative this is an error. Check the return on callers side to inform there is an error in reading the voltage, instead of notifying of a too low voltage. Signed-off-by: Maxime Coquelin <[email protected]>
As the libusb returns errors, make the backends propagates them so that callers can decide to continue or stop task execution. Signed-off-by: Maxime Coquelin <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
Now that libusb errors are propagated up to stlink API, we can handle these errors. Signed-off-by: Maxime Coquelin <[email protected]>
Having a type of flash information has some advantages: - Make the code easier to read - Make adding family derivatives easier (only add a new entry in header file) - Make the backends error propagation easier to implement (less places to fix) Signed-off-by: Maxime Coquelin <[email protected]>
This patch simplifies run_flash_loader() function in preparation for error propagation from backends. Doing this, we have less call sites for stlink API. Signed-off-by: Maxime Coquelin <[email protected]>
This patch invert source and destination registers in the stm32l0 and stm32l1 loaders, so that it follows the same ABI as other stm32 loaders. Doing that, the run_flash_loader() function can be simplified a little. Signed-off-by: Maxime Coquelin <[email protected]>
All the loaders returns remaining work count in r2, except stm32l0/1. Make these loaders behaving as the others to simplify run_flash_loader() code. Signed-off-by: Maxime Coquelin <[email protected]>
…larity The stm32l4 loader expects a count of 32 bits words while its granularity is really 64 bits. This patch fixes this to simplify count calculation in run_flash_loader(). Signed-off-by: Maxime Coquelin <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
Hi, thanks for the work, looks fine. However, it won't be merged it as is. Until now, a single commit targets a specific feature / fix which makes Thus, I encourage you to break the commit into individual pieces. Cheers 2016-03-14 15:26 GMT+01:00 mcoquelin-stm32 [email protected]:
|
Hi, Thanks for the review. Thanks in advance, |
Thanks! |
No, that is fine. Thanks |
Dear Texane,
This pull-request contains some preliminary reworks to have complete error propagation from libusb to st-flash tool.
I also changed some loaders to "commonize" their handling.
Please let me know what you thinkabout it.
Thanks in advance,
Maxime