STM32L erase/write should work again!

32 views
Skip to first unread message

Uwe Bonnes

unread,
Dec 18, 2011, 9:44:40 AM12/18/11
to stm3...@googlegroups.com
Hello,

my github stlink branch at
github.com:UweBonnes/stlink.git
carries changes, that let me program the STM32L Discovery again. I
appreciate feedback before I send out the pull request to Fabien

Thank
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Karl P

unread,
Dec 18, 2011, 3:25:28 PM12/18/11
to stm3...@googlegroups.com, Uwe Bonnes

the CLI flash tool works, but gdb still seems broken. It doesn't even detect
the chip properly. (this is just your branch, nothing of my code)

Karl P

unread,
Dec 18, 2011, 4:43:46 PM12/18/11
to Uwe Bonnes, stm3...@googlegroups.com

I realllly feel that load device params should be in the connection. Which is
why I'd put it there in the first place. Moving such a required call _out_ of
the init is just asking for trouble. Init should... init!

On 12/18/2011 09:00 PM, Uwe Bonnes wrote:
>>>>>> "Karl" == Karl P<ka...@tweak.net.au> writes:
>
> Karl> the CLI flash tool works, but gdb still seems broken. It doesn't
> Karl> even detect the chip properly. (this is just your branch, nothing
> Karl> of my code)
>
> I now added the same initialization to the gdbserver as there is in
> flash/main.c.
>

Uwe Bonnes

unread,
Dec 18, 2011, 4:00:13 PM12/18/11
to Karl P, stm3...@googlegroups.com
>>>>> "Karl" == Karl P <ka...@tweak.net.au> writes:

Karl> the CLI flash tool works, but gdb still seems broken. It doesn't
Karl> even detect the chip properly. (this is just your branch, nothing
Karl> of my code)

I now added the same initialization to the gdbserver as there is in
flash/main.c.

--

Uwe Bonnes

unread,
Dec 18, 2011, 5:42:58 PM12/18/11
to Karl P, Uwe Bonnes, stm3...@googlegroups.com
>>>>> "Karl" == Karl P <ka...@tweak.net.au> writes:

Karl> I realllly feel that load device params should be in the
Karl> connection. Which is why I'd put it there in the
Karl> first place.
Karl> Moving such a required call _out_ of the init
Karl> is just asking for
Karl> trouble. Init should... init!

Moved the calls to the stlink_open functions.

Reply all
Reply to author
Forward
0 new messages