impressiver/arm-utilities

Automatically exported from code.google.com/p/arm-utilities

arm-utilities's Issues

Incomplete work-around for STLink USB bugs

What steps will reproduce the problem?
1. Plug in a STLink
2. Attempt to use it immediately
3. Hilarity ensues

What is the expected output? What do you see instead?

You expect to be able to use the device immediately.

The device pretends to be a USB mass storage device ("flash key").  But it
only implements the bare minimum needed to fool Windows.  When Linux tries
to read the partition table, the device responds incorrectly, triggering
many retries before the Linux kernel gives up trying to recover from the error.

One part of the solution may be to write a udev rule that treats the STLink 
device specially, turning off automount attempts.

I have been able to write udev rules to create /dev/stlink with appropriate 
ownership and permissions, but have not yet figured out where to block the 
automount.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 6 Mar 2011 at 10:42

stlink-download can't write to flash memory unless windows tools are used first

What steps will reproduce the problem?
1. Buy a STM32Discovery Board
2. Try to use stlink-download
3.

What is the expected output? What do you see instead?
stlink-download can't write to flash memory

What version of the product are you using? On what operating system?

Please provide any additional information below.
It looks like the board comes with the flash locked, you have to use the 
windows tools once to unlock it then stlink-download works fine.
I know this is not really a bug but it took me a while to figure it out and 
hopefully this will stop other people getting as frustrated as me! 

Original issue reported on code.google.com by [email protected] on 11 Jun 2011 at 1:09

stlink-download: Timing problem after writing first block to flash

What steps will reproduce the problem?
  1. Flashing a binary whose size exceeds 2048 byte

What is the expected output? What do you see instead?
  Rereading the bytes after the flash process returns 0xff
  (Verifying is not implemented, but returns 0 :-)

What version of the product are you using? On what operating system?
  arm-utilities-2011-6-28, Linux

Please provide any additional information below.

I have had a problem with a bin file whose size exceeds 2048 byte.
In my case only the first 2048 bytes were written.

There might be a timing problem while waiting for the status.
I have just added a sleep as long as the status is not STLINK_CORE_HALTED

# Before

 Writing ARM memory 0x08000000..0x08020000 from /home/mc/vc/rhaag/microcontroller/arm/stm32f100/apps/demo-gpio-basic/src/../build/demo-gpio-basic-stm32f100.bin.
Read 2324 bytes from file 
/home/mc/vc/rhaag/microcontroller/arm/stm32f100/apps/demo-gpio-basic/src/../buil
d/demo-gpio-basic-stm32f100.bin
Flash write 08000000..08000914, size 2324/914.
 SCSI residue was 4, sense length 0.
 SCSI residue was 4, sense length 0.
Flash status 00, control 0004.
Flash write: Run 1, size 2324, chunk size 2048, offset 0
 SCSI residue was 4, sense length 0.
 SCSI residue was 4, sense length 0.
Flash status 20, control 0001 status 80.

# Patched

 Writing ARM memory 0x08000000..0x08020000 from /home/mc/vc/rhaag/microcontroller/arm/stm32f100/apps/demo-gpio-basic/src/../build/demo-gpio-basic-stm32f100.bin.
Read 2324 bytes from file 
/home/mc/vc/rhaag/microcontroller/arm/stm32f100/apps/demo-gpio-basic/src/../buil
d/demo-gpio-basic-stm32f100.bin
Flash write 08000000..08000914, size 2324/0x914.
 SCSI residue was 4, sense length 0.
 SCSI residue was 4, sense length 0.
Flash status 00, control 0004.
Flash write: Run 1, size 2324, chunk size 2048, offset 0
Status is 128, sleeping ...
Flash write: Run 2, size 276, chunk size 276, offset 2048
Status is 128, sleeping ...
 SCSI residue was 4, sense length 0.
Flash write succeeded

I've attached a patch which solves the problem for me.

Original issue reported on code.google.com by [email protected] on 2 Jul 2011 at 8:29

Attachments:

• patch