Discovery board analog/digital inputs not working?

[Jason Nanna]

Hi, thought I'd share an update - I built this prototype a few days ago but am still having problems seeing a response from the analog/digital inputs.  I used PA0-7 for the analog inputs and PB0-1 / PC0-5 for the digital inputs.  I poked around at the source code a bit, it certainly doesn't seem like the board define does much at all, I'm not sure what else might be an issue here...?

I assume all one needs to do is include a GPIO input in the patch...  is there more to it than this?  I am actively pulling my digital inputs high or low so I know they should be set to high impedance.  The example patches didn't seem to have any response either.

[Johannes Taelman]

Hi Jason,

Check Table 5 in the STM32F4Discovery manual (DM00039084.pdf) for pin conflicts:

PA4 is used for the CS43L22 codec
PA5, PA6, PA7 are used for the on-board accelerometer

PC0 for USB power control
PC3 for the on-board microphone.

Normally the gpio/in/analog, gpio/in/digital, gpio/out/analog, gpio/out/digital objects do not require anything else. Almost all testing happened on the Axoloti Core board, making it compatible with the STM32F4Discovery board was a quick hack, I only tested midi in and audio out.

The issue for the analog inputs is situated in void ui_init(void) function in ui.c, where the ADC pin setup happens to be. I'll sort that out later today...

I don't see immediately what the issue is with the digital I/O apart from the pin conflicts.

best,

Johannes

On Sat, Dec 20, 2014 at 3:53 PM, Jason Nanna <jason...@gmail.com> wrote:

Hi, thought I'd share an update - I built this prototype a few days ago but am still having problems seeing a response from the analog/digital inputs.  I used PA0-7 for the analog inputs and PB0-1 / PC0-5 for the digital inputs.  I poked around at the source code a bit, it certainly doesn't seem like the board define does much at all, I'm not sure what else might be an issue here...?

I assume all one needs to do is include a GPIO input in the patch...  is there more to it than this?  I am actively pulling my digital inputs high or low so I know they should be set to high impedance.  The example patches didn't seem to have any response either.

--
You received this message because you are subscribed to the Google Groups "axoloti-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axoloti-user...@googlegroups.com.
To post to this group, send email to axolot...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/axoloti-users/a88f7c58-5831-47e8-9f53-bfd009af62ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Johannes Taelman]

A fix for non-working gpio/in/analog on the Discovery board is committed on the git. You will need to recompile firmware and flash again.
Tell me if it works as expected now.

best,

Johannes

[Jason Nanna]

No - it's not working at all...  First, I couldn't get the build process working again.  The first firmware I built seemed to build just great.  Now I can't get it to build either through NetBeans or MinGW on windows...  So instead I set up a build environment on Linux, got it to partially build (the 'flasher' makefile didn't work but the firmware was successful) so I grabbed the firmware and put it in my windows environment, flashed the firmware, and it connects and immediately disconnects.  Just to be sure I tried flashing the old firmware back on it, that still works fine. The only thing I've changed to my previously working windows axoloti environment is to add the firmware to /firmware/build .

I've attached it here in case it's useful.  Perhaps I need to have that 'flasher' makefile successfully build and include that as well?

On my linux machine I used javac from openjdk6-jre.  There weren't any errors.

[Jason Nanna]

A little more info - under Linux the makefile in flasher first complained it couldn't find build/obj/* so I simply copied the entire build directory into flasher and then got this.  Perhaps I have some environment problems.  I'll try to poke around at this some more in Windows with netbeans, I think.

smrl@smrlbench:~/axoloti/firmware/flasher$ make

arm-none-eabi-gcc     build/obj/crt0.o build/obj/vectors.o build/obj/chcore.o build/obj/chcore_v7m.o build/obj/nvic.o build/obj/chsys.o build/obj/chdebug.o build/obj/chlists.o build/obj/chvt.o build/obj/chschd.o build/obj/chthreads.o build/obj/chdynamic.o build/obj/chregistry.o build/obj/chsem.o build/obj/chmtx.o build/obj/chcond.o build/obj/chevents.o build/obj/chmsg.o build/obj/chmboxes.o build/obj/chqueues.o build/obj/chmemcore.o build/obj/chheap.o build/obj/chmempools.o build/obj/hal.o build/obj/adc.o build/obj/can.o build/obj/ext.o build/obj/gpt.o build/obj/i2c.o build/obj/icu.o build/obj/mac.o build/obj/mmc_spi.o build/obj/mmcsd.o build/obj/pal.o build/obj/pwm.o build/obj/rtc.o build/obj/sdc.o build/obj/serial.o build/obj/serial_usb.o build/obj/spi.o build/obj/tm.o build/obj/uart.o build/obj/usb.o build/obj/stm32_dma.o build/obj/hal_lld.o build/obj/adc_lld.o build/obj/ext_lld_isr.o build/obj/can_lld.o build/obj/ext_lld.o build/obj/mac_lld.o build/obj/sdc_lld.o build/obj/pal_lld.o build/obj/i2c_lld.o build/obj/usb_lld.o build/obj/rtc_lld.o build/obj/spi_lld.o build/obj/gpt_lld.o build/obj/icu_lld.o build/obj/pwm_lld.o build/obj/serial_lld.o build/obj/uart_lld.o build/obj/board.o build/obj/fatfs_diskio.o build/obj/fatfs_syscall.o build/obj/ff.o build/obj/shell.o build/obj/chprintf.o build/obj/memstreams.o build/obj/glcdfont.o build/obj/axoloti_control.o build/obj/axoloti_board.o build/obj/sdcard.o build/obj/main.o   -mcpu=cortex-m4 -O2 -ggdb -fomit-frame-pointer -falign-functions=16 -ffunction-sections -fdata-sections -fno-common -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -nostartfiles -L. -Wl,-Map=build/flasher.map,--cref,--no-warn-mismatch,--library-path=,--script=STM32F407xG.ld,--gc-sections -mno-thumb-interwork -mthumb   -o build/flasher.elf

/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/bin/ld: build/flasher.elf section `.sram2' will not fit in region `SRAM'

/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/bin/ld: region `SRAM' overflowed by 3932 bytes

build/obj/chmemcore.o: In function `_core_init':

/home/smrl/axoloti/firmware/../chibios/os/kernel/src/chmemcore.c:71: undefined reference to `__heap_base__'

/home/smrl/axoloti/firmware/../chibios/os/kernel/src/chmemcore.c:71: undefined reference to `__heap_end__'

build/obj/axoloti_control.o: In function `do_axoloti_control':

/home/smrl/axoloti/firmware/axoloti_control.c:41: undefined reference to `Btn_Nav_Or'

/home/smrl/axoloti/firmware/axoloti_control.c:41: undefined reference to `Btn_Nav_And'

/home/smrl/axoloti/firmware/axoloti_control.c:41: undefined reference to `EncBuffer'

build/obj/sdcard.o: In function `SDLoadPatch':

/home/smrl/axoloti/firmware/sdcard.c:195: undefined reference to `StopPatch'

/home/smrl/axoloti/firmware/sdcard.c:209: undefined reference to `StartPatch'

build/obj/main.o: In function `main':

/home/smrl/axoloti/firmware/main.c:77: undefined reference to `InitPatch0'

/home/smrl/axoloti/firmware/main.c:79: undefined reference to `InitPConnection'

/home/smrl/axoloti/firmware/main.c:95: undefined reference to `axoloti_math_init'

/home/smrl/axoloti/firmware/main.c:96: undefined reference to `midi_init'

/home/smrl/axoloti/firmware/main.c:97: undefined reference to `codec_init'

/home/smrl/axoloti/firmware/main.c:102: undefined reference to `ui_init'

/home/smrl/axoloti/firmware/main.c:103: undefined reference to `StartLoadPatchTread'

/home/smrl/axoloti/firmware/main.c:117: undefined reference to `StartPatch'

/home/smrl/axoloti/firmware/main.c:117: undefined reference to `patchStatus'

collect2: error: ld returned 1 exit status

../../chibios/os/ports/GCC/ARMCMx/rules.mk:207: recipe for target 'build/flasher.elf' failed

make: *** [build/flasher.elf] Error 1

[Johannes Taelman]

Jason.

Don't worry about the "flasher" thing. Its a trick to upgrade firmware without needing DFU mode, by copying the firmware from pc to sdcard first and then copying that firmware into flash. I haven't build it for a while, and it is likely borken.

To compile the firmware, just use the "compile firmware" menu-item in the board menu. If you have it installed according to the documentation, that should work, if not, let's work out those issues.

I'm not using NetBeans or MingW directly to build the firmware. I use Netbeans to edit and build the Java GUI only, not for the firmware.

If you can't connect after flashing: could you try erasing the flash memory completely before flashing - for instance with the STM32 ST-link utility?

Flash sector 11 is used for storing a patch binary to run in standalone mode. Patch binaries are not compatible across different firmwares (statically linked) and crash the startup process. I added a quick check for this last week to solve this, but that may still have an issue...

Thanks for your patience!

To view this discussion on the web visit https://groups.google.com/d/msgid/axoloti-users/8e84f4a3-fe9f-4439-b1df-2ee6fbd0009b%40googlegroups.com.

[Jason Nanna]

OK, so I went through the process of getting the environment set back up so I could document a bit of what I went through to get everything in order.  So, from the beginning:

git clone https://github.com/JohannesTaelman/axoloti.git

from command shell
./get_dependencies.bat

in msys:
./get_dependencies.sh

platform_win/compile_gui.bat:

JavaHome: C:\Program Files\Java\jdk1.8.0_25
C:\Program Files\Java\jdk1.8.0_25;C:\Program Files\Java\jdk1.8.0_25\bin;"C:\Program Files (x86)\NetBeans 8.0\extide\ant\bin";"C:\Program Files\NetBeans 8.0\extide\ant\bin"
'ant' is not recognized as an internal or external command, operable program or batch file.

- however, I can run 'ant' from the command line just fine.

Upon further inspection, ant is in C:\Program Files\NetBeans 8.0.2\extide\ant\bin

edit compile_gui.bat and fix path to netbeans.

Start axoloti.  

Board/firmware/compile.

Start compiling firmware
'make' is not recognized as an internal or external command,
operable program or batch file.
shell task successful!
Link to firmware ID Please compile the firmware first
Done compiling firmware

OK, so get_dependencies didn't take care of make.

Looking into that, it appears that the downloaded unzip.exe is not working, even though I have unzip.exe in MinGW and it works.  So I delete unzip.exe and try again with MinGW's unzip.

Back in axoloti, board/firmware/compile
shell task successful!
Link to firmware ID 9164B1B0

Hey!  Looks like it worked.  Uploading firmware using ST-link. Jolly good!

Unfortunately, same result.
connected

Disconnect request

transmitter: thread stopped

[Jason Nanna]

ST-Link utility doesn't work either - no ST-link detected.  Could this be because of the LibusbK?  I am sorry I have to admit to quite a bit of ignorance as to how this all works - I've done stuff with AVR's before, but this is all new to me...

[Jason Nanna]

One other comment - I could not get the DFU mode to work at all yet, so I've been using ST-Link mode to upload. (yet STM32-ST-Link utility detects no ST-LINK?)  This did work for the earlier version of the firmware I used.

C:\Users\smrl\Desktop\axoloti>cd C:\Users\smrl\Desktop\axoloti\platform_win\\bin 

C:\Users\smrl\Desktop\axoloti\platform_win\bin>dfu-util --device 0483:df11 -i 0 -a 0 -D ../../firmware/build/axoloti.bin --dfuse-address=0x08000000 

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2014 Tormod Volden and Stefan Schmidt

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to dfu-...@lists.gnumonks.org

Invalid DFU suffix signature

A valid DFU suffix will be required in a future dfu-util release!!!

No DFU capable USB device available

shell task failed, exit value: 74

Done flashing firmware with DFU

[Johannes Taelman]

Hi Jason,

Thanks for your install notes, I'll try to reproduce and improve things, your notes are really helpful!

No working connect: did you apply the mods for the STM32F4Discovery board?

[Jason Nanna]

duh.  no.  i'll try :)

[Johannes Taelman]

DFU flashing is enabled on the STM32F4Discovery by bridging BOOT0 and VDD during power-on and sits on the micro-USB port. On Axoloti Core this is enabled by holding S1 during power-on. This needs the UsbK driver on windows.
After DFU flashing you need to power-cycle the board, dfu-util does not seem to be able to reset the target and leave DFU mode unfortunately.

STLink is the on-board debugger on the STM32F4Discovery, connected via its mini-USB. It is not present on the Axoloti Core board but it can be connected (needed for firmware debugging). I can't recall swapping a driver for it.

On Sunday, December 21, 2014 6:39:05 PM UTC+1, Jason Nanna wrote:

One other comment - I could not get the DFU mode to work at all yet, so I've been using ST-Link mode to upload. (yet STM32-ST-Link utility detects no ST-LINK?)  This did work for the earlier version of the firmware I used.

C:\Users\smrl\Desktop\axoloti>cd C:\Users\smrl\Desktop\axoloti\platform_win\\bin 

C:\Users\smrl\Desktop\axoloti\platform_win\bin>dfu-util --device 0483:df11 -i 0 -a 0 -D ../../firmware/build/axoloti.bin --dfuse-address=0x08000000 

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2014 Tormod Volden and Stefan Schmidt

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to xxxxxxxxxxxxxx

[Jason Nanna]

Thanks.  It works now, I just totally overlooked modifying the source for the Discovery board.  :/  What are the advantages of DFU flashing?  

[Jason Nanna]

And the inputs are working now!  Thanks so much for your patch!

[Johannes Taelman]

The DFU USB bootloader present in the microcontroller ROM, so it can not get corrupted.

ST-Link flashing has no disadvantage on the STM32F4Discovery board. The additional electronics required for it is just not present on the Axoloti Core board.

--

You received this message because you are subscribed to the Google Groups "axoloti-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axoloti-user...@googlegroups.com.
To post to this group, send email to axolot...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/axoloti-users/c05ba14c-80f5-49a5-9948-150aba3a1bf1%40googlegroups.com.