utzig / lm4tools Goto Github PK

View Code? Open in Web Editor NEW

200.0 200.0 50.0 81 KB

Tools to enable multi-platform development on the TI Stellaris Launchpad boards

Makefile 5.85% C 94.15%

lm4tools's People

Contributors

Stargazers

Watchers

lm4tools's Issues

Suspect license of project0.bin

I worry that project0 that comes from stellarisware cannot be redistributed in binary form:

There are US export restrictions and usage applications (non military) that (you) had to accept while downloading stellarisware from TI website. This makes (you) liable to the breach of that agreement.
The source file that project0.bin is built from contains the following license (see /boards/ek-lm4f120xl/project0/project0.c):

// project0.c - Example to demonstrate minimal StellarisWare setup
//
// Copyright (c) 2012 Texas Instruments Incorporated. All rights reserved.
// Software License Agreement
//
// Texas Instruments (TI) is supplying this software for use solely and
// exclusively on TI's microcontroller products. The software is owned by
// TI and/or its suppliers, and is protected under applicable copyright
// laws. You may not combine this software with "viral" open-source
// software in order to form a larger program.
//
// THIS SOFTWARE IS PROVIDED "AS IS" AND WITH ALL FAULTS.
// NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT
// NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. TI SHALL NOT, UNDER ANY
// CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
// DAMAGES, FOR ANY REASON WHATSOEVER.
//
// This is part of revision 9453 of the EK-LM4F120XL Firmware Package.

TI explicitly reserves all rights. The license agreement states that the software may not be combined (which is not the case here as it is not combined with lm4tools in any way) but does not explicitly grant anyone the right to re-distribute the program.

This is not a plea for removing project0.bin from the tree but a reminder that it should be understood better (contacting TI might be applicable) or replaced with a version that has no such claims.

Since the project0 source code is very simple, perhaps it would be possible to provide a pure-assembly re-implementation that would be undoubtedly legal to include.

No ICDI device found

On Mac OS X 10.6.8:

$ lm4flash/lm4flash project0.bin
No ICDI device with USB VID:PID 1cbe:00fd found!

What are the prerequisites for the OS to recognize the device?

lm4flash hangs w/slow target SysClock

I've been using lm4flash to develop on my TM4C123GLX for six months or so. No problem until yesterday. I was progressively slowing down the CPU clock to test some PWM code that's not behaving. It doesn't make sense to me that this could be the cause, but it's the only thing I can think of that has changed.

The currently flashed code calls ROM_SysCtlClockSet(SYSCTL_SYSDIV_64 | SYSCTL_USE_OSC | SYSCTL_OSC_INT4); => System Clock at 62.5kHz
This seems about right, as my program is still running and outputting UART data that correlates with that clock speed.

I've recompiled lm4flash with the "#define DEBUG 1" line active, so I have a debug stream I could send (looks like a series of memory queries, a FlashErase, then hangs on the "FlashWrite" command (sending 537 bytes). I'm trying to load a small, known good .bin file (blinky.bin - 804bytes).

EDIT: I should also say that I left it overnight (not really thinking it would take that long) & also borrowed a friend's Win7 machine, loaded TI's LM Flash & ICDI drivers, but it could not find the target. I've not tried it before, so have no idea if it's a Win7 config issue or the device. But I'm sure something happened to my Linux setup (with no host computer changes).

fopen: No such file or directory

root@crypto:/home/username/Embedded/lm4tools/lm4flash# ./lm4flash ~/Embedded/tiva-template/build/main.bin
Found ICDI device with serial: 0E21335F
fopen: No such file or directory

without root I got a below output
Unable to open USB device: LIBUSB_ERROR_ACCESS
Unable to find any ICDI devices

I'm using Ubuntu 16.04.1 (x64) .TM4C123GXL Launchpad

when I disassemble the gdb64 . I put breakpoint line 766 of lm4flash.c output is
(gdb) x/xw rom_name
0x7fffffffe74d: 0x6f6f722f
(gdb) x/s rom_name
0x7fffffffe74d: "/root/Embedded/tiva-template/build/main.bin"

No ICDI device found on some of the USB ports

On my ThinkPad W510 running Windows 7, lm4flash doesn't work o the two SuperSpeed USB ports on the left side of the machine.
It works fine on the USB port at the back, as well as on the combined eSATA/USB port on the left (next to the two SuperSpeed ports).
When it doesn't work, it displays the following error message:
No ICDI device with USB VID:PID 1cbe:00fd found!
Failed!

The specific lm4flash.exe version is the one shipped on the latest Energia 0101E0009 (sorry, I don't know exactly what version it is).
I tested this issue by running the lm4flash.exe executable on the Windows command line without Energia.

lmicdi dumps core when cannot open device

you should fail&exit, probably with perror (permission denied) and hint user, that he or she should run program as privileged user. Otherwise core is dumped with following:

#0  0x006482cd in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x00567436 in pthread_mutex_lock () from /lib/libc.so.6
#2  0x05baa49b in libusb_claim_interface (dev=0x0, interface_number=2) at core.c:1287
#3  0x08049287 in main (argc=1, argv=0xbfd97ff4) at lmicdi.c:290

compile lm4flash under cygwin

If you want to compile lm4flash under cygwin on windows, you need to edit out the '_snprintf' define from lm4flash.c:

$ diff -u lm4flash.c.org lm4flash.c
--- lm4flash.c.org      2023-01-26 10:15:12.975382500 +0100
+++ lm4flash.c  2023-01-26 13:57:36.635529600 +0100
@@ -67,7 +67,7 @@
 #define END "#"

 #ifdef WIN32
-#define snprintf _snprintf
+// #define snprintf _snprintf
 #define SNPRINTF_OFFSET 1
 #else
 #define SNPRINTF_OFFSET 0

Avoid hardcoding `/usr/local` in lmicdusb Makefile

The lmicdiusb Makefile hardcodes /usr/local for Darwin at

lm4tools/lmicdiusb/Makefile

Lines 40 to 41 in 61a7d17

 LIBUSB_CFLAGS := -I/usr/local/include/libusb-1.0 

 LIBUSB_LIBDIR := /usr/local/lib

This isn't always where libusb can be found (e.g. if libusb were installed via MacPorts, or on an M1 Mac via Homebrew), so it would be nice if this could be made more flexible.

I can try to find the time to send a patch when I'm less busy. (A new macOS version was recently released, so it's a busy time for Homebrew at the moment.)

Related: Homebrew/homebrew-core#88207

Unable to find any ICDI devices (on beaglebone running debian 10)

I am running debian 10, and had lm4flash installed, along with libusb

When I list all USB devices, it indicates TiVa is detected in Device 012, and ready to receive new flash

debian@beaglebone:~/monoApp$ lsusb
Bus 001 Device 011: ID 1cbe:00ff Luminary Micro Inc. Stellaris ROM DFU Bootloader
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

When I run lm4flash, I got this

debian@beaglebone:~/monoApp$ lm4flash -v 4208.bin
Unable to open USB device: LIBUSB_ERROR_ACCESS
Unable to find any ICDI devices

This first error line may not appear if i experiment different VID/PID (lm4flash will be rebuilt to match VID/PID)

Any pointer? Thanks!

Support for selecting device by serial

I have two stellaris boards attached to my machine. I would like to be able to specify which device to flash, ideally using the iSerial descriptor.

Track issues remaining till first release

I'd like to create a milestone, say, 0.1 but that value is arbitrary, to track issues that need to be fixed before you can release the first version of lm4tools

Stuck Flashing

Flashing works fine with project0.bin, but when I try to flash with my own program, it gets stuck. I am compiling with Yagarto and when flashing it is stuck after getting the ICDI version. Here's the console log:

matt@wraith:~/Projects/OpenSource/helios$ make -j4


Compiling main.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -Os -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I /Users/matt/Projects/Embedded/Stellaris/StellarisWare/ -DPART_LM4F120H5QR -c -DTARGET_IS_BLIZZARD_RA1 -I/Users/matt/bin/yagarto/yagarto-4.7.1/arm-none-eabi/include/  main.c -o main.o

Compiling startup.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -Os -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I /Users/matt/Projects/Embedded/Stellaris/StellarisWare/ -DPART_LM4F120H5QR -c -DTARGET_IS_BLIZZARD_RA1 -I/Users/matt/bin/yagarto/yagarto-4.7.1/arm-none-eabi/include/  startup.c -o startup.o
Compiling servo.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -Os -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I /Users/matt/Projects/Embedded/Stellaris/StellarisWare/ -DPART_LM4F120H5QR -c -DTARGET_IS_BLIZZARD_RA1 -I/Users/matt/bin/yagarto/yagarto-4.7.1/arm-none-eabi/include/  servo.c -o servo.o
startup.c:13:0: warning: ignoring #pragma DATA_SECTION  [-Wunknown-pragmas]

Making driverlib
make -C /Users/matt/Projects/Embedded/Stellaris/StellarisWare/driverlib/
make[2]: Nothing to be done for `all'.
make[2]: Nothing to be done for `all'.

Linking...
arm-none-eabi-ld -T LM4F.ld --gc-sections -o helios.axf main.o servo.o startup.o /Users/matt/Projects/Embedded/Stellaris/StellarisWare/driverlib/gcc-cm4f/libdriver-cm4f.a /Users/matt/bin/yagarto/yagarto-4.7.1/bin/../lib/gcc/arm-none-eabi/4.7.1/../../../../arm-none-eabi/lib/thumb/v7m/libm.a /Users/matt/bin/yagarto/yagarto-4.7.1/bin/../lib/gcc/arm-none-eabi/4.7.1/../../../../arm-none-eabi/lib/thumb/v7m/libc.a /Users/matt/bin/yagarto/yagarto-4.7.1/bin/../lib/gcc/arm-none-eabi/4.7.1/thumb/v7m/libgcc.a

Copying...
arm-none-eabi-objcopy -Obinary helios.axf helios.bin

Creating list file...
arm-none-eabi-objdump -S helios.axf > helios.lst
matt@wraith:~/Projects/OpenSource/helios$ make load
sudo /Users/matt/Projects/OpenSource/lm4tools/lm4flash/lm4flash helios.bin -v
Found ICDI device with serial: 0E1018F6
ICDI version: 9454
      # !! STUCK HERE !!! CTRL-C
^Cmake: *** [load] Error 130

lmicdi hangs for a long time after "Calling handle_events()"

This set-up used to work on earlier versions of Fedora (I can't remember as it was a while ago, but maybe F22 x64?). Now I'm on Fedora 24 x64 I seem to get a hang when connecting with GDB.

Running GDB:

$ arm-none-eabi-gdb ./target/lm4f120/release/bare-metal-arm-rust
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/jonathan/Documents/programming/rust/bare-metal-arm-rust/target/lm4f120/release/bare-metal-arm-rust...(no debugging symbols found)...done.
(gdb) target remote :7777
Remote debugging using :7777
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...

Running lmicdi I get a very long pause, then libusb starts returning -6 (LIBUSB_ERROR_BUSY).

nDevs = 7
Considering device 0
Found device with matching VID and PID.  pDev = 0x74b2b0
iCfg = 0
        iIf = 0
                iAlt = 0
                Interface name (index 0, len = -2) = ''
        iIf = 1
                iAlt = 0
                Interface name (index 0, len = -2) = ''
        iIf = 2
                iAlt = 0
                Interface name (index 0, len = -2) = ''
                        iEndp = 0
                        Found ENDPOINT_IN
                        iEndp = 1
                        Found ENDPOINT_OUT
bind to port 7777
listen
accept...
doGdb: USB activity.  Calling handle_events()
<there's a very long pause here>
doGdb: USB activity.  Called handle_events() // I added this TRACE call
doGdb: Fd[1].revents = 0
doGdb: Fd[2].revents = 0
doGdb: Fd[3].revents = 0
doGdb: Fd[0].revents = 0
doGdb: Fd[1].revents = 0
doGdb: Fd[2].revents = 0
doGdb: socketFd.revents = 0x00000041
doGdb: recv returned 269
GDB_IDLE: '+'
GDB_IDLE: '$'
GDB_PAYLOAD: 'q' 0x71
GDB_PAYLOAD: 'S' 0x53
GDB_PAYLOAD: 'u' 0x75
GDB_PAYLOAD: 'p' 0x70
GDB_PAYLOAD: 'p' 0x70
GDB_PAYLOAD: 'o' 0x6f
GDB_PAYLOAD: 'r' 0x72
GDB_PAYLOAD: 't' 0x74
GDB_PAYLOAD: 'e' 0x65
GDB_PAYLOAD: 'd' 0x64
GDB_PAYLOAD: ':' 0x3a
GDB_PAYLOAD: 'm' 0x6d
GDB_PAYLOAD: 'u' 0x75
GDB_PAYLOAD: 'l' 0x6c
GDB_PAYLOAD: 't' 0x74
GDB_PAYLOAD: 'i' 0x69
GDB_PAYLOAD: 'p' 0x70
GDB_PAYLOAD: 'r' 0x72
GDB_PAYLOAD: 'o' 0x6f
GDB_PAYLOAD: 'c' 0x63
GDB_PAYLOAD: 'e' 0x65
GDB_PAYLOAD: 's' 0x73
GDB_PAYLOAD: 's' 0x73
GDB_PAYLOAD: '+' 0x2b
GDB_PAYLOAD: ';' 0x3b
GDB_PAYLOAD: 'q' 0x71
GDB_PAYLOAD: 'R' 0x52
GDB_PAYLOAD: 'e' 0x65
GDB_PAYLOAD: 'l' 0x6c
GDB_PAYLOAD: 'o' 0x6f
GDB_PAYLOAD: 'c' 0x63
GDB_PAYLOAD: 'I' 0x49
GDB_PAYLOAD: 'n' 0x6e
GDB_PAYLOAD: 's' 0x73
GDB_PAYLOAD: 'n' 0x6e
GDB_PAYLOAD: '+' 0x2b
GDB_PAYLOAD: '#' 0x23
GDB_CSUM1: '2'
GDB_CSUM2: 'a'
usbTxReq: '+$qSupported:multiprocess+;qRelocInsn+#2a'
usbTxReq: ...done
GDB_IDLE: '$'
GDB_PAYLOAD: 'q' 0x71
GDB_PAYLOAD: 'S' 0x53
GDB_PAYLOAD: 'u' 0x75
GDB_PAYLOAD: 'p' 0x70
GDB_PAYLOAD: 'p' 0x70
GDB_PAYLOAD: 'o' 0x6f
GDB_PAYLOAD: 'r' 0x72
GDB_PAYLOAD: 't' 0x74
GDB_PAYLOAD: 'e' 0x65
GDB_PAYLOAD: 'd' 0x64
GDB_PAYLOAD: ':' 0x3a
GDB_PAYLOAD: 'm' 0x6d
GDB_PAYLOAD: 'u' 0x75
GDB_PAYLOAD: 'l' 0x6c
GDB_PAYLOAD: 't' 0x74
GDB_PAYLOAD: 'i' 0x69
GDB_PAYLOAD: 'p' 0x70
GDB_PAYLOAD: 'r' 0x72
GDB_PAYLOAD: 'o' 0x6f
GDB_PAYLOAD: 'c' 0x63
GDB_PAYLOAD: 'e' 0x65
GDB_PAYLOAD: 's' 0x73
GDB_PAYLOAD: 's' 0x73
GDB_PAYLOAD: '+' 0x2b
GDB_PAYLOAD: ';' 0x3b
GDB_PAYLOAD: 'q' 0x71
GDB_PAYLOAD: 'R' 0x52
GDB_PAYLOAD: 'e' 0x65
GDB_PAYLOAD: 'l' 0x6c
GDB_PAYLOAD: 'o' 0x6f
GDB_PAYLOAD: 'c' 0x63
GDB_PAYLOAD: 'I' 0x49
GDB_PAYLOAD: 'n' 0x6e
GDB_PAYLOAD: 's' 0x73
GDB_PAYLOAD: 'n' 0x6e
GDB_PAYLOAD: '+' 0x2b
GDB_PAYLOAD: '#' 0x23
GDB_CSUM1: '2'
GDB_CSUM2: 'a'
usbTxReq: '$qSupported:multiprocess+;qRelocInsn+#2a'
usbTxReq: ERROR rc = -6
usbTxReq: ...done

Incorrect FSF address in license

Pointed out by rpmlint tool.

lm4flash.i686: E: incorrect-fsf-address /usr/share/doc/lm4flash-0/COPYING
The Free Software Foundation address in this file seems to be outdated or
misspelled. Ask upstream to update the address, or if this is a license file,
possibly the entire file with a new copy available from the FSF.

There is an updated license file with current FSF address on GNU website.

Can't compile on Debian Squeeze

When I try to compile under Debian Squeeze I get the following errors:

gcc -Wall -g -O2 -I/usr/include/libusb-1.0   lm4flash.c -lusb-1.0   -o lm4flash
lm4flash.c: In function ‘flasher_find_matching_device’:
lm4flash.c:595: warning: implicit declaration of function ‘libusb_error_name’
lm4flash.c:595: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
lm4flash.c:612: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
lm4flash.c:626: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
lm4flash.c:637: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
lm4flash.c: In function ‘flasher_flash’:
lm4flash.c:699: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
lm4flash.c:709: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
lm4flash.c:725: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
lm4flash.c:732: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int’
/tmp/ccUWh2Hw.o: In function `flasher_find_matching_device':
/home/thinkbrown/Stellaris/lm4tools/lm4flash/lm4flash.c:611: undefined reference to `libusb_error_name'
/home/thinkbrown/Stellaris/lm4tools/lm4flash/lm4flash.c:625: undefined reference to `libusb_error_name'
/home/thinkbrown/Stellaris/lm4tools/lm4flash/lm4flash.c:594: undefined reference to `libusb_error_name'
/home/thinkbrown/Stellaris/lm4tools/lm4flash/lm4flash.c:636: undefined reference to `libusb_error_name'
/tmp/ccUWh2Hw.o: In function `flasher_flash':
/home/thinkbrown/Stellaris/lm4tools/lm4flash/lm4flash.c:698: undefined reference to `libusb_error_name'
/tmp/ccUWh2Hw.o:/home/thinkbrown/Stellaris/lm4tools/lm4flash/lm4flash.c:724: more undefined references to `libusb_error_name' follow
collect2: ld returned 1 exit status
make: *** [lm4flash] Error 1

When I try it in my Debian Wheezy VM it compiles without any errors. Am I to take it that the version of libusb that's in the Squeeze repos is too old?

$ brew install libusb

I plug in my Stellaris Launchpad to the debug USB and am getting this everytime I try to flash it:

$ ./lm4flash/lm4flash project0.bin 
Unable to get device serial number: LIBUSB_ERROR_OTHER
Unable to find any ICDI devices

I get this if I unplug it:

$ ./lm4flash/lm4flash project0.bin 
Unable to find any ICDI devices

Unable to open USB device: LIBUSB_ERROR_ACCESS

I am using Linux Mint on Windows 7 machine using VMware. Besides working perfectly for a few times, it always give me the following error:

akhilpo-virtual-machine ~/work/stellaris-work $ lm4flash blinky.bin
Unable to open USB device: LIBUSB_ERROR_ACCESS
Unable to find any ICDI devices

I tried reconnecting the device several times.

	LIBUSB_CFLAGS := -I/usr/local/include/libusb-1.0
	LIBUSB_LIBDIR := /usr/local/lib

utzig / lm4tools Goto Github PK

lm4tools's People

Contributors

Stargazers

Watchers

Forkers

lm4tools's Issues

Recommend Projects

Recommend Topics

Recommend Org