stm32f4 discovery board?
Locked
1234
1234
|
======= 2011-11-06 13:57:34 ：=======
>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. This not a problem for us. The ST library used in this port is the 1.0.0, not 1.0.0RC1. > >> 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 = = = = = = = = = = = = = = = = = = = = _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by jbsnyder
I've been able to upload the image using dfu-util, but I can't figure
the default eLua serial port. I tried using an usb->serial adapter on pins PB6/PB7 as well as on USART1 and was expecting to see eLua prompt, but hot nothing. Were I looking at the wrong pins? Is there a way to tell if eLua was succesfully loaded (other then the terminal)? I could load ST demo programs just fine using the same version from dfu-util. Thanks, Pedro. On Mon, Oct 24, 2011 at 1:44 AM, James Snyder <[hidden email]> wrote: > 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 eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Feb 6, 2012 at 10:28 PM, Pedro <[hidden email]> wrote:
> I've been able to upload the image using dfu-util, but I can't figure > the default eLua serial port. > > I tried using an usb->serial adapter on pins PB6/PB7 as well as on > USART1 and was expecting to see eLua prompt, but hot nothing. > Were I looking at the wrong pins? Is there a way to tell if eLua was > succesfully loaded (other then the terminal)? I could load ST demo > programs just fine using the same version from dfu-util. I believe those pins should be correct. Are you sure you didn't flip the pins or set the baud rate to one that doesn't match the default (8N1 115200) If you've been able to load other bin files successfully, I'd guess your flashing tools are working correctly. I can generate and check an image tomorrow if that might be helpful in debugging. Have you changed any build settings or are you going straight out of the repo? > > Thanks, > Pedro. > > On Mon, Oct 24, 2011 at 1:44 AM, James Snyder <[hidden email]> wrote: >> 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 > _______________________________________________ > 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 |
|
|
Double checked pins, parity and connections.
Changed no settings, straight out of the repo. I'll try to add a led blinking code and recompile, just so that I can be sure eLua is actually there. On Tue, Feb 7, 2012 at 2:55 AM, James Snyder <[hidden email]> wrote: > On Mon, Feb 6, 2012 at 10:28 PM, Pedro <[hidden email]> wrote: >> I've been able to upload the image using dfu-util, but I can't figure >> the default eLua serial port. >> >> I tried using an usb->serial adapter on pins PB6/PB7 as well as on >> USART1 and was expecting to see eLua prompt, but hot nothing. >> Were I looking at the wrong pins? Is there a way to tell if eLua was >> succesfully loaded (other then the terminal)? I could load ST demo >> programs just fine using the same version from dfu-util. > > I believe those pins should be correct. Are you sure you didn't flip > the pins or set the baud rate to one that doesn't match the default > (8N1 115200) If you've been able to load other bin files > successfully, I'd guess your flashing tools are working correctly. > > I can generate and check an image tomorrow if that might be helpful in > debugging. Have you changed any build settings or are you going > straight out of the repo? > >> >> Thanks, >> Pedro. >> >> On Mon, Oct 24, 2011 at 1:44 AM, James Snyder <[hidden email]> wrote: >>> 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 >> _______________________________________________ >> 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 |
|
|
I messed up with dfu-util parameters. Recompiled, reflashed with the
correct parameters (as documented on the wiki) and it worked. Sorry for the noise, and thanks for the attention. On Tue, Feb 7, 2012 at 3:08 AM, Pedro <[hidden email]> wrote: > Double checked pins, parity and connections. > > Changed no settings, straight out of the repo. > > I'll try to add a led blinking code and recompile, just so that I can > be sure eLua is actually there. > > On Tue, Feb 7, 2012 at 2:55 AM, James Snyder <[hidden email]> wrote: >> On Mon, Feb 6, 2012 at 10:28 PM, Pedro <[hidden email]> wrote: >>> I've been able to upload the image using dfu-util, but I can't figure >>> the default eLua serial port. >>> >>> I tried using an usb->serial adapter on pins PB6/PB7 as well as on >>> USART1 and was expecting to see eLua prompt, but hot nothing. >>> Were I looking at the wrong pins? Is there a way to tell if eLua was >>> succesfully loaded (other then the terminal)? I could load ST demo >>> programs just fine using the same version from dfu-util. >> >> I believe those pins should be correct. Are you sure you didn't flip >> the pins or set the baud rate to one that doesn't match the default >> (8N1 115200) If you've been able to load other bin files >> successfully, I'd guess your flashing tools are working correctly. >> >> I can generate and check an image tomorrow if that might be helpful in >> debugging. Have you changed any build settings or are you going >> straight out of the repo? >> >>> >>> Thanks, >>> Pedro. >>> >>> On Mon, Oct 24, 2011 at 1:44 AM, James Snyder <[hidden email]> wrote: >>>> 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 >>> _______________________________________________ >>> 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 |
|
|
On Mon, Feb 6, 2012 at 11:24 PM, Pedro <[hidden email]> wrote:
> I messed up with dfu-util parameters. Recompiled, reflashed with the > correct parameters (as documented on the wiki) and it worked. > > Sorry for the noise, and thanks for the attention. No worries. It would be nice to the dfu firmware files that embed the information that gets included in that command line. I might look at that again when I'm working on finally merging this thing :-) > > On Tue, Feb 7, 2012 at 3:08 AM, Pedro <[hidden email]> wrote: >> Double checked pins, parity and connections. >> >> Changed no settings, straight out of the repo. >> >> I'll try to add a led blinking code and recompile, just so that I can >> be sure eLua is actually there. >> >> On Tue, Feb 7, 2012 at 2:55 AM, James Snyder <[hidden email]> wrote: >>> On Mon, Feb 6, 2012 at 10:28 PM, Pedro <[hidden email]> wrote: >>>> I've been able to upload the image using dfu-util, but I can't figure >>>> the default eLua serial port. >>>> >>>> I tried using an usb->serial adapter on pins PB6/PB7 as well as on >>>> USART1 and was expecting to see eLua prompt, but hot nothing. >>>> Were I looking at the wrong pins? Is there a way to tell if eLua was >>>> succesfully loaded (other then the terminal)? I could load ST demo >>>> programs just fine using the same version from dfu-util. >>> >>> I believe those pins should be correct. Are you sure you didn't flip >>> the pins or set the baud rate to one that doesn't match the default >>> (8N1 115200) If you've been able to load other bin files >>> successfully, I'd guess your flashing tools are working correctly. >>> >>> I can generate and check an image tomorrow if that might be helpful in >>> debugging. Have you changed any build settings or are you going >>> straight out of the repo? >>> >>>> >>>> Thanks, >>>> Pedro. >>>> >>>> On Mon, Oct 24, 2011 at 1:44 AM, James Snyder <[hidden email]> wrote: >>>>> 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 >>>> _______________________________________________ >>>> 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 eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |