-
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 <mcoquelin.stm32@gmail.com>
This rework is done in order to prepare for propagating errors returned by libusb. Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
_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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Now that libusb errors are propagated up to stlink API, we can handle these errors. Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
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 <mcoquelin.stm32@gmail.com>
…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 <mcoquelin.stm32@gmail.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
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 notifications@github.com:
|
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