Re: recent patches...
Karl P
>>>>>> "Karl" == Karl P<ka...@tweak.net.au> writes:
>
> Karl> Just going through and actually reviewing and merging your latest
> Karl> changes. texane's approach of "merge ALL the patches" isn't
> Karl> working out so well.
>
> Sorry. But I sent the pull request with "please review" attached.
heh, I don't think texane's doing much reviewing to be honest.
> Karl> Also, you totally completely busted flash writing on the 32L
> Karl> devices. I've fixed gdb, but I'm still going over the code. I
> Karl> suspect it's some side affect of part of the "write_debug32"
> Karl> stuff, but I haven't covered it yet.
>
> The debug32 register stuff should be like a no-op. I will try to find time
> to go over it again.
I spent a while on it last night, and I agree, it should be fine. can't see
what's not there yet.
>
> Karl> I understand that it made
> Karl> some code easier to read, instead of using a buffer to do a single
> Karl> word write, but was there any actual net gain there?
>
> It is removing USB transaction. Before it was
> - send header and address
> - wait for ack
> - send data
>
> Now it is only
> - send header/address/data
> - wait for ack
Hmm, interesting. I hadn't noticed that.
>
> Karl> I take it you only have a F1xx target? If you've got changes like
> Karl> this, I'm more than happy to test it out on the 32L target for
> Karl> you. (I recently got an F4 too, but I haven't done much with it
> Karl> yet)
>
> I have all STM discovery boards, the STEVAL-PCC010V2 and a home designed
> STM32F107 board. Actually the home brewn board has the only output channel I
> can use at the moment, so my tests were only with the F107. Have to refine
> my test procedure...
>
> The next week some board will arrive, were I actually use the STM32L
> Eval. So all errors fall back to me...
Sorry, I forgot to mention I've fixed gdb and done some more tidying up in my
merge-test branch at github. I was also tidying up the recently merged OSX
changes for stlink v1 support. It's got a few other bits of cleanup that hasn't
yet been merged back into texane's branch. (I wanted to test some of it a bit
more first....)
Cheers,
Karl P
Karl P
On 12/17/2011 04:17 PM, Uwe Bonnes wrote:
>>>>>> "Karl" == Karl P<ka...@tweak.net.au> writes:
>
> Karl> Just going through and actually reviewing and merging your latest
> Karl> changes. texane's approach of "merge ALL the patches" isn't
> Karl> working out so well.
>
> Most important:
> - Do you have patches pending?
Nothing critical, but yeah, I have a bunch of tidy up that should go in at some
stage.
> - Should I ask Texane to revert?
Depends how long it takes to fix the 32L flashing :) Some of the other stuff is
good and useful, if it can be made to work. Currently, however, this is more
backwards than forwards. If at least this patch is applied:
https://github.com/karlp/stlink/commit/b76b7893d7fc3754ba91dbab881d1db20291276b
Then at least gdb works again for people.
I've been working too much recently, and spent a few hours on this last night,
but I'm a bit exhausted by it to be honest. reverting would at least put it
back to a known stable(ish) place.
Uwe Bonnes
Karl> Just going through and actually reviewing and merging your latest
Karl> changes. texane's approach of "merge ALL the patches" isn't
Karl> working out so well.
Sorry. But I sent the pull request with "please review" attached.
Karl> First, removing the load_params() calls from the backend open
Karl> calls was a bad idea. Obviously you don't use gdb. :)
I must admit, I didn't test the changes with gdb.
Karl> By removing
Karl> it from the backend open, and adding it into the _flash_
Karl> application, gdb was totally busted.
You are right! I didn't think about gdb...
Karl> Anyway. I'm curious about your WFI problems. By reading the arch
Karl> docs, the debug register unlock key that you added should only be
Karl> necessary when you want to use the debug features. I can
Karl> understand the change in 9ef6d28cb5751c0cf589136181569f585059a8bc
Karl> to make the end of the flash code do a, "exit debug mode" rather
Karl> than a reset and run, though I imagine there's going to be some
Karl> debate about that. But unlocking the debug registers, when you
Karl> are _exiting_ debug mode doesn't make any real sense to me. Are
Karl> you sure the unlock there is necessary?
Not really ;-)
Karl> Can you try it again
Karl> without that line please?
Will do!
Karl> Also, you totally completely busted flash writing on the 32L
Karl> devices. I've fixed gdb, but I'm still going over the code. I
Karl> suspect it's some side affect of part of the "write_debug32"
Karl> stuff, but I haven't covered it yet.
The debug32 register stuff should be like a no-op. I will try to find time
to go over it again.
Karl> I understand that it made
Karl> some code easier to read, instead of using a buffer to do a single
Karl> word write, but was there any actual net gain there?
It is removing USB transaction. Before it was
- send header and address
- wait for ack
- send data
Now it is only
- send header/address/data
- wait for ack
Karl> I take it you only have a F1xx target? If you've got changes like
Karl> this, I'm more than happy to test it out on the 32L target for
Karl> you. (I recently got an F4 too, but I haven't done much with it
Karl> yet)
I have all STM discovery boards, the STEVAL-PCC010V2 and a home designed
STM32F107 board. Actually the home brewn board has the only output channel I
can use at the moment, so my tests were only with the F107. Have to refine
my test procedure...
The next week some board will arrive, were I actually use the STM32L
Eval. So all errors fall back to me...
Thanks for your patients!
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes
Karl> Just going through and actually reviewing and merging your latest
Karl> changes. texane's approach of "merge ALL the patches" isn't
Karl> working out so well.
Most important:
- Do you have patches pending?
- Should I ask Texane to revert?
Bye