On Mon, Oct 17, 2011 at 9:48 PM, Roger Critchlow <[hidden email]> wrote:
Someone posted a comment on HaD describing how to use stlink: (sorry, no direct link to the comment) Once you have GDB up and running, flashing should be as easy as running a "load" command (I think) from GDB. Also, this would make an EXCELLENT hardware debugger.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by Roger Critchlow
On Mon, Oct 17, 2011 at 1:48 PM, Roger Critchlow <[hidden email]> wrote:
> More progress, it appears that this stlink interface package: > https://github.com/texane/stlink > has been upgraded to support the STLinkV2 on the STM32F4 and other boards. > I haven't tried it, yet, but a poster on hackaday says it works, and sure > enough the source has a udev rule for the new 0483:4788 STLink device. Very nice. I'd prefer something usblib-based so that it would be portable to OS X, but between this and the other mentions out there it sounds like there should be decent support for at least flashing and maybe debugging this device on multiple platforms without the need for special hardware or proprietary/expensive software packages. Perhaps we should convert the link on the wiki into a page discussing some of these items so that we can keep track of all of this as a resource as well all start receiving these kits? I'll start: http://wiki.eluaproject.net/STM32F4DISCOVERY This is quite refreshing given that the LPCXpresso board has an LPC-LINK device on it that doesn't seem to be supported by anyone and this seems to be a bit nicer in terms of specs and lower priced :-) > -- rec -- > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by jbsnyder
On 10/16/2011 10:24 AM, James Snyder wrote:
> Any further progress made on the interface from something other than > windows? I've requested a sample of one of these boards to experiment > with and saw a flurry of messages related to the interface but nothing > entirely conclusive? > > Perhaps if all else fails there may be some way to get the mcu into a > dfu mode and upload firmware that way? > There's an "stlink" project on github that appears to have gdb server code for both STLINK/V1 and STLINK/V2. https://github.com/texane/stlink I haven't had a chance to try it yet, but it looks promising. -- Ned Konz Product Creation | Studio 425 Westlake Av. N Seattle, WA 98109 PH 206-297-7200 http://productcreationstudio.com _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Dado Sutter |
In reply to this post by Tim Michals
On Mon, Oct 17, 2011 at 12:06, Tim michals <[hidden email]> wrote:
Nice ! More and more boards coming. RAM is very welcomed :) Thank you for mentioning them here. Pros and cons for eLua on the kits, including new candidates, are being kept on the Wiki at http://wiki.eluaproject.net/Boards Help is very welcomed to edit this and every other page. There are so many new candidates now that they might be better on a page of their own. Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by Dado Sutter
As I'm new to elua community and has trouble to check in files, so I write a blog and shares code in it, the url is:
http://dd.homeunix.com/home/space.php?uid=1&do=blog&id=90 (The blog server displays Chinese but the blog content is in English) STM32F2 support was also added, the same zip file contains both F2 and F4 support. I also put some lessons learned in this blog, for example, if you program the chip and then have trouble to connect it, me experience might helps. If anyone is working on it, feel free to use my code and added into eLua repository. |
In reply to this post by Ned Konz-2
On Mon, Oct 17, 2011 at 7:16 PM, Ned Konz <[hidden email]> wrote:
It works fine, more or less according to the documentation. I've modified the blink example for the STM32F4 Discovery, loaded it into ram with gdb, and continued it successfully.
But loading to flash did not succeed, never completed, generated 24Mbytes of log file, and it seems to have gummed up my system. And the board is still happily running the demo, so nothing got written.
-- rec -- _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by Zhanjun Dong
On 10/17/2011 08:33 PM, Zhanjun Dong wrote:
> As I'm new to elua community and has trouble to check in files, so I write a > blog and shares code in it, the url is: > > http://dd.homeunix.com/home/space.php?uid=1&do=blog&id=90 > (The blog server displays Chinese but the blog content is in English) > > STM32F2 support was also added, the same zip file contains both F2 and F4 > support. > I also put some lessons learned in this blog, for example, if you program > the chip and then have trouble to connect it, me experience might helps. > > If anyone is working on it, feel free to use my code and added into eLua > repository. I just submitted these changes as a pull request. -- Ned Konz Product Creation | Studio 425 Westlake Av. N Seattle, WA 98109 PH 206-297-7200 http://productcreationstudio.com _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Thanks. I just got my board today. I'll try to take a look at this
pull request and either merge it or put it in a branch for now if it requires further modification before making it into the trunk. I guess one of the first questions I would have is whether or not we need to split stm32 into stm32, stm32f2, stm32f4 or whether they can realistically coexist as one port, but I'll take a look. It looks like there's a lot of common code, but currently there's at least some non-working peripherals like CAN on F4? Best. -jsnyder On Tue, Oct 18, 2011 at 12:34 PM, Ned Konz <[hidden email]> wrote: > On 10/17/2011 08:33 PM, Zhanjun Dong wrote: >> >> As I'm new to elua community and has trouble to check in files, so I write >> a >> blog and shares code in it, the url is: >> >> http://dd.homeunix.com/home/space.php?uid=1&do=blog&id=90 >> (The blog server displays Chinese but the blog content is in English) >> >> STM32F2 support was also added, the same zip file contains both F2 and F4 >> support. >> I also put some lessons learned in this blog, for example, if you program >> the chip and then have trouble to connect it, me experience might helps. >> >> If anyone is working on it, feel free to use my code and added into eLua >> repository. > > I just submitted these changes as a pull request. > > -- > Ned Konz > Product Creation | Studio > 425 Westlake Av. N > Seattle, WA 98109 > PH 206-297-7200 > http://productcreationstudio.com > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Also, would like to see the version of the ST library used, from time to time ST does rev the library..or follow the same directory structure to make the diffs easier. From: James Snyder <[hidden email]> To: eLua Users and Development List (www.eluaproject.net) <[hidden email]> Sent: Tuesday, October 18, 2011 1:16 PM Subject: Re: [eLua-dev] stm32f4 discovery board? Thanks. I just got my board today. I'll try to take a look at this pull request and either merge it or put it in a branch for now if it requires further modification before making it into the trunk. I guess one of the first questions I would have is whether or not we need to split stm32 into stm32, stm32f2, stm32f4 or whether they can realistically coexist as one port, but I'll take a look. It looks like there's a lot of common code, but currently there's at least some non-working peripherals like CAN on F4? Best. -jsnyder On Tue, Oct 18, 2011 at 12:34 PM, Ned Konz <[hidden email]> wrote: > On 10/17/2011 08:33 PM, Zhanjun Dong wrote: >> >> As I'm new to elua community and has trouble to check in files, so I write >> a >> blog and shares code in it, the url is: >> >> http://dd.homeunix.com/home/space.php?uid=1&do=blog&id=90 >> (The blog server displays Chinese but the blog content is in English) >> >> STM32F2 support was also added, the same zip file contains both F2 and F4 >> support. >> I also put some lessons learned in this blog, for example, if you program >> the chip and then have trouble to connect it, me experience might helps. >> >> If anyone is working on it, feel free to use my code and added into eLua >> repository. > > I just submitted these changes as a pull request. > > -- > Ned Konz > Product Creation | Studio > 425 Westlake Av. N > Seattle, WA 98109 > PH 206-297-7200 > http://productcreationstudio.com > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Eureka, or almost.
The stlink project doesn't write the flash. The dfu-util project doesn't talk to the stm32, and I temporarily bricked my board when I tried hacking the protocol. But this project, http://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util, just wrote the demonstration binary back onto the board, so my ex-brick is now flashing its leds again. And it's willing to flash raw .bin files, too, as well as the ST v1.1a dfu suffixed files.
My image doesn't work when flashed, but that will be easier to fix with a way to flash the image.
-- rec -- _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by jbsnyder
Hi,
On Tue, Oct 18, 2011 at 9:16 PM, James Snyder <[hidden email]> wrote: Thanks. I just got my board today. I'll try to take a look at this Good question, indeed. For now I _think_ they can co-exist as a single port since they share so much code in common, but I have to take a closer look at this.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by Roger Critchlow
On Wed, Oct 19, 2011 at 1:23 AM, Roger Critchlow <[hidden email]> wrote:
> Eureka, or almost. > The stlink project doesn't write the flash. The dfu-util project doesn't > talk to the stm32, and I temporarily bricked my board when I tried hacking > the protocol. > But this > project, http://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util, just > wrote the demonstration binary back onto the board, so my ex-brick is now > flashing its leds again. And it's willing to flash raw .bin files, too, as > well as the ST v1.1a dfu suffixed files. > My image doesn't work when flashed, but that will be easier to fix with a > way to flash the image. I believe I have this working as well. Of note for those who might plan to try this tool, for me at least I needed to use the "dfuse-libusb-1.0" branch from the above repo, otherwise it didn't like the dfu image from ST's firmware package. > -- rec -- > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
On Thu, Oct 20, 2011 at 8:25 PM, James Snyder <[hidden email]> wrote:
Sorry, I should have remembered to mention that essential detail. -- rec -- _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
And speaking of essential details about the dfuse-dfu-util package, this option
-s --dfuse-address address ST DfuSe mode, specify target address for
raw file download or upload. Not applicable for DfuSe file (.dfu) downloads
-- rec -- On Thu, Oct 20, 2011 at 8:43 PM, Roger Critchlow <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
OK, I've got it working locally for me with a secondary usb->serial
adapter connected to PB6/PB7 (connected, respectively, to RXD/TXD on the FTDI link). I took Ned's merge request and started working on integrating the new timer changes, which don't appear to be fully working yet, but it does boot to the shell. I've put my additional hackery based on Ned's pull request here: https://github.com/jsnyder/elua/tree/bikeNomad-master I'm able to get programming working when in DFU mode with dfuse-dfu-util with the following build then dfu-util commands: scons board=STM32F4DSCY prog dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -s 0x08000000 -D elua_lua_stm32f407vg.bin I have not extensively looked at merging the ports into a common directory yet, this was just a first pass to get things booting for me and merged with trunk. FYI: I did not attempt any merging of the STM32F2 work done by Zhanjun Dong towards using the new system timers so I suspect that doesn't build at the moment. Thanks everyone for the various pieces :-) -jsnyder On Thu, Oct 20, 2011 at 11:18 PM, Roger Critchlow <[hidden email]> wrote: > And speaking of essential details about the dfuse-dfu-util package, this > option > -s --dfuse-address address ST DfuSe mode, specify target address for > raw file download or upload. Not applicable for > DfuSe file (.dfu) downloads > is required to download raw .bin files, and the error with it omitted > doesn't help figure that out. > -- rec -- > On Thu, Oct 20, 2011 at 8:43 PM, Roger Critchlow <[hidden email]> wrote: >> >> >> On Thu, Oct 20, 2011 at 8:25 PM, James Snyder <[hidden email]> >> wrote: >>> >>> On Wed, Oct 19, 2011 at 1:23 AM, Roger Critchlow <[hidden email]> wrote: >>> > Eureka, or almost. >>> > The stlink project doesn't write the flash. The dfu-util project >>> > doesn't >>> > talk to the stm32, and I temporarily bricked my board when I tried >>> > hacking >>> > the protocol. >>> > But this >>> > project, http://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util, >>> > just >>> > wrote the demonstration binary back onto the board, so my ex-brick is >>> > now >>> > flashing its leds again. And it's willing to flash raw .bin files, >>> > too, as >>> > well as the ST v1.1a dfu suffixed files. >>> > My image doesn't work when flashed, but that will be easier to fix with >>> > a >>> > way to flash the image. >>> >>> I believe I have this working as well. Of note for those who might >>> plan to try this tool, for me at least I needed to use the >>> "dfuse-libusb-1.0" branch from the above repo, otherwise it didn't >>> like the dfu image from ST's firmware package. >>> >> Sorry, I should have remembered to mention that essential detail. >> -- rec -- > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
On Mon, Oct 24, 2011 at 6:44 AM, James Snyder <[hidden email]> wrote:
OK, I've got it working locally for me with a secondary usb->serial Just a quick note: the system timer should be easy to adapt. Make sure you have a working systick interrupt, then follow the implementation of any of the existing M3 platforms (LM3S, STM32, LPC1768). Since all the components involved here (the system timer and the interrupt system) are basically the same on all of them, you shouldn't have too much work to do.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by jbsnyder
Sorry for the late reply, I didn't check email yesterday.
Thanks for your integrating. I'm very glad that we could working together and push things moving forward. About timer or other features like CAN, my latest code did not apply all my works on F2, will working on it later. About F2/F4, I compare all .h files in ST library for F2 V1.0.0 and F4 V1.0.0, most files has exactly the SAME content, except the 2xx/4xx, only very few and minor different found in GPIO I2C PWR RCC RTC SPI USART, looks like merge F2/F4 into 1 common line should be easy and safe, at least for F2 and F4. |
A few updates on the STM32F4 Discovery.
1) The dfuse emulation code has been merged into the main dfu-util development tree, the version 0.50 release at http://dfu-util.gnumonks.org/ has it included, or you can clone git://git.openezx.org/dfu-util.git.
2) ST has released an updated firmware package, version 1.1.0 replacing 1.0.1. 3) The updated firmware package includes a firmware updater that grabs a new image.bin off a usb key drive and writes it into flash.
-- rec --
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
The updated package is for discovery kit demo, the F4 library is still the V1.0.0.
I will take a look if any changes for discovery kit relevants to current port. Sincerely Zhanjun Dong ======= 2011-11-06 00:11:28 :======= >A few updates on the STM32F4 Discovery. > >1) The dfuse emulation code has been merged into the main dfu-util >development tree, the version 0.50 release at http://dfu-util.gnumonks.org/ has >it included, or you can clone git://git.openezx.org/dfu-util.git. > >2) ST has released an updated firmware package, version 1.1.0 replacing >1.0.1. > >3) The updated firmware package includes a firmware updater that grabs a >new image.bin off a usb key drive and writes it into flash. > >-- rec -- > >_______________________________________________ >eLua-dev mailing list >[hidden email] >https://lists.berlios.de/mailman/listinfo/elua-dev > = = = = = = = = = = = = = = = = = = = = _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
2011/11/6 Zhanjun Dong <[hidden email]>:
> The updated package is for discovery kit demo, the F4 library is still the V1.0.0. It looks like there's a DSP/peripheral lib out at 1.0.0, and the firmware package for the discovery board got updated with the usb key loading among other things. It looks like the peripheral lib was updated to 1.0.0 from 1.0.0RC1. It looks like the changes are fairly minor, not sure if any of them have direct affects. > I will take a look if any changes for discovery kit relevants to current port. > > Sincerely > Zhanjun Dong > > ======= 2011-11-06 00:11:28 :======= > >>A few updates on the STM32F4 Discovery. >> >>1) The dfuse emulation code has been merged into the main dfu-util >>development tree, the version 0.50 release at http://dfu-util.gnumonks.org/ has >>it included, or you can clone git://git.openezx.org/dfu-util.git. This is quite nice to see. I'll update the wiki to reflect this. As an additional note, I have been merging in Zhanjun's changes to the git branch provided by bikeNomad: https://github.com/jsnyder/elua/tree/bikeNomad-master ADC should now work at least for the first 4 channels now. I'm going to make some changes shortly to make the ADC pin configuration work more like some other platforms where pins are configured as needed when they're updated as being needed in the sequence. The system timers should be working as well, though I'll admit I haven't rechecked them in the latest build. This is shaping up into a nice platform. Thanks for all the help everyone :-) >> >>2) ST has released an updated firmware package, version 1.1.0 replacing >>1.0.1. >> >>3) The updated firmware package includes a firmware updater that grabs a >>new image.bin off a usb key drive and writes it into flash. >> >>-- rec -- >> >>_______________________________________________ >>eLua-dev mailing list >>[hidden email] >>https://lists.berlios.de/mailman/listinfo/elua-dev >> > > = = = = = = = = = = = = = = = = = = = = > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Free forum by Nabble | Edit this page |