Alternative dso firmware [Application Software Design Entry]

[gabonator1]

I have found this:
http://infocenter.arm.com/help/topic/co ... CAIGH.html

linker switch "--no_blx_thumb_arm" that prevents using BLX... unfortunately no such switch is supported by toolchain I am using.

But I have found this:

Code: Select all

C:\Programs\Devel\Gcc\arm-2011.03\arm-none-eabi\bin>ld --help | find "blx"
  --use-blx                   Enable use of BLX instructions

Explanation:
The `--use-blx' switch enables the linker to use ARM/Thumb BLX instructions (available on ARMv5t and above) in various situations. Currently it is used to perform calls via the PLT from Thumb code using BLX rather than using BX and a mode-switching stub before each PLT entry. This should lead to such calls executing slightly faster.

it seems that it is enabled by default and no way to turn it off.... I tried setting -march-armv3 but it produced the same assembly

Update:
I managed to work around the BLX issue, by enabling long calls "-mlong-calls" it will produce this assembly:

Code: Select all

Disassembly of section .text:

20005000 <main>:
20005000:       b513            push    {r0, r1, r4, lr}
20005002:       4b05            ldr     r3, [pc, #20]   ; (20005018 <main+0x18>)
20005004:       2014            movs    r0, #20
20005006:       9300            str     r3, [sp, #0]
20005008:       21a0            movs    r1, #160        ; 0xa0
2000500a:       2200            movs    r2, #0
2000500c:       f64f 73ff       movw    r3, #65535      ; 0xffff
20005010:       4c02            ldr     r4, [pc, #8]    ; (2000501c <main+0x1c>)
20005012:       47a0            blx     r4
20005014:       2001            movs    r0, #1
20005016:       bd1c            pop     {r2, r3, r4, pc}
20005018:       20005020        .word   0x20005020
2000501c:       200050e0        .word   0x200050e0
20005020:       6c6c6548        .word   0x6c6c6548
20005024:       2121216f        .word   0x2121216f
        ...

Disassembly of section .plt:

200050cc <.plt>:
200050cc:       e52de004        push    {lr}            ; (str lr, [sp, #-4]!)
200050d0:       e59fe004        ldr     lr, [pc, #4]    ; 200050dc <_ebss+0x18>
200050d4:       e08fe00e        add     lr, pc, lr
200050d8:       e5bef008        ldr     pc, [lr, #8]!
200050dc:       00000064        .word   0x00000064
200050e0:       e28fc600        add     ip, pc, #0, 12     <---- here
200050e4:       e28cca00        add     ip, ip, #0, 20
200050e8:       e5bcf064        ldr     pc, [ip, #100]! ; 0x64

Now it hangs at 200050e0. Now I am a little bit confused - does the stm32f108 support ARM 32 bit instructions?

[skorpionm]

May still be soldered to the DSO miniSD card
Owners board version 2.7 can be happy for them developer made connector. power to make it through the diode 3.3V

CIMG0255.JPG

2.6 The owners will have to solder the 98 pin (PE1) controller.
Will need 93 pin (PB7) software to translate into a high level, thus disabling the built-in flash, signals MOSI, MSCK, MISO take with integrated flash, and 98 pin (PE1) in selecting a low SD card.
Also implement a normal file system on the card FAT32. example

htt ps://mb ed. org/coo kbook/ SD-C ard-File-Sy ste m <--remove spaces from URL

And in the flash controller to leave only the BIOS, the file system, Explorer to select downloads, and will be all happy. 32 Gb enough for all applications

datasheet dso203v2.7

DS203 V2.7.pdf

There is also an additional 2 free pin (PC0, PC1 on the board R33, R34) which can also be used (for example to check a MicroSD slot)

[tormod]

this is my build script... the problem will be somewhere else, but thanks for a try

Code: Select all

set CFLAGS=-Wall -Werror -Os -fno-common -mcpu=cortex-m3 -mthumb -msoft-float -MD -std=c99 -Wno-psabi 
set LDFLAGS=-nostartfiles -mcpu=cortex-m3 -mthumb -march=armv7 -mfix-cortex-m3-ldrd -msoft-float 

rem Build library
!CC! !CFLAGS! -c -Wall -Werror -fpic ../library.c
!CC! !LDFLAGS! -shared -o libbios.so library.o

rem Build example
!CC! !CFLAGS! -S ../main.c
!CC! !CFLAGS! -c ../main.c
!CC! -T ../APP2main.lds !LDFLAGS! -Wl,-dynamic-linker,gloader.1 -Wl,-emain main.o -o !TFILE!_!APP!.elf -lbios -L.

I don't understand why you are using the -march=armv7 option. It should be enough to specify -mcpu=cortex-m3 which already defines the architecture. Also. the architecture for the cortex-m3 used in STM32F103 is armv7-m and not armv7. Possibly your conflicting architecture specification fools the toolchain into allowing ARM instructions.

Disassembly of section .plt:

200050b8 <.plt>:
200050b8: e52de004 push {lr} ; (str lr, [sp, #-4]!)
200050bc: e59fe004 ldr lr, [pc, #4] ; 200050c8 <_ebss+0x18>
200050c0: e08fe00e add lr, pc, lr
200050c4: e5bef008 ldr pc, [lr, #8]!
200050c8: 00000064 .word 0x00000064
200050cc: e28fc600 add ip, pc, #0, 12
200050d0: e28cca00 add ip, ip, #0, 20
200050d4: e5bcf064 ldr pc, [ip, #100]! ; 0x64
[/code]

You can see all instructions in the .plt section are 4 bytes wide, a typical sign of ARM instructions and not Thumb. This is the root of your problem: The toolchain has compiled and labelled this code as ARM code and therefore also calls into it with pair addresses (like 0x200050cc, or 0x200050e0 in your other post).

[gabonator1]

I tried armv7-m but there is no change in PLT... the problem of generating thumb PLT entries by gcc was already discussed 10 years ago:

http://www.sourceware.org/ml/binutils/2 ... 00439.html

but they did not implement the patch it into bintools, I tried patching it manually, but the current source of elf32-arm.c was heavily changed during that long period, and I am not in a mood to dig into this huge 14000 lines long messy code. Anyway there is already support for custom PLT behavior (for vxworks), and there is some suspicious code with thumb instructions, but I don't know how to force the gcc to use it (tried armv7-m & fPIC/fpic):

bintools-2.20.1/bfd/elm32-arm.c

Code: Select all

/* Thumb -> Thumb long branch stub, PIC. Used on M-profile
   architectures.  */
static const insn_sequence elf32_arm_stub_long_branch_thumb_only_pic[] =
  {
    THUMB16_INSN(0xb401),             /* push {r0} */
    THUMB16_INSN(0x4802),             /* ldr  r0, [pc, #8] */
    THUMB16_INSN(0x46fc),             /* mov  ip, pc */
    THUMB16_INSN(0x4484),             /* add  ip, r0 */
    THUMB16_INSN(0xbc01),             /* pop  {r0} */
    THUMB16_INSN(0x4760),             /* bx   ip */
    DATA_WORD(0, R_ARM_REL32, 4),     /* dcd  R_ARM_REL32(X) */
  };

I followed this tutorial for building arm toolchain on windows pc with msys and mingw:
http://www.microbuilder.eu/Tutorials/So ... chain.aspx

here is the function that chooses the right plt stub type:
http://pastebin.com/Ly3BtJwj
the condition for using the previous entry is following: thub_only && (r_type == R_ARM_THM_CALL || r_type == R_ARM_THM_JUMP24) && st_type == STT_ARM_TFUNC

thumb_only is set for 'M' type of architectures (armv7-m), so I probably need to set the relocation type in my "library" to R_ARM_THM_CALL instead of R_ARM_JUMP_SLOT... but how to achieve this?

[pelegrino.tricorder]

Hi, I received my DSO QUAD , make a update with the correct code.

All is the scope is fine, except the function generator...

When I tell to generate Square Wave, the frequency is correct.
When I change to Triangle, or Sawtooth, ou Sin HQ, the real frequency generated is 4 times greater than the specified.
And When I specified Sin LQ, the real frequency generated is 16 times greater !
I used my desk digital scope to the measures.

My original HW was 2.72, I put first all the files from comunity APP, that works ok, then I use the Gabonator's code.
My last try today was reflashing the FPGA code, but the result is the same.

And one curiosity, after the Gabonator code, my HW info shows 2.60, and when I go to the ABOUT Menu, in the Device, this is the result :

Hardware Version : 2.60
System version : 1.50 SmTech 1.6
FPGA version : 0.00 <- what the hell !!!
DFU version : 3.10
Display Driver : ILI9327
Serial Number : 7d24a570

What I can do to fix the Function Generator ?

Thanks.

[owen.hann]

I would like to use the RS232 ability of the Gabonator alternative firmware (which is truly excellent, although development seems to have ceased some while back ). I have searched and searched but not been able to find out how the RS323 signal is actually input into the DS203.

On the page https://github.com/gabonator/DS203, the very first screenshot seems to indicate that the RS232 signal is extracted from the input on channel A and a second signal from channel B. The threshold taken as the 'zero' marker "1" and "2" respectively.

This is exactly what I want to do... look at the analog waveform on the oscilloscope, and simultaneously decode it and display the string on the screen!

Other pages allude to cutting open the DS203 and connecting to the 'genuine' UART (TX & RX pins on CN7) to achieve RS232 comms.

Anyone done something like what I want to do?
If the input is indeed from one of the analog channels, how do I get to it, and is there an 'invert' for signals that appear on the 'inside' (logic side) of a level converter (eg:MAX232)?
Is there any information out there on the 'UART' function that Gabonator has put in his firmware?

Cheers,
Owen.

[kmewparity]

Hi, I just got my new latest DS203. It is with HW v2.81. But I bricked it while updating the firmware.

Does anyone dumped the DFU v3.04c? So that I can flush my DSO.

[ba54]

Hi

I really like the UI of this firmware but I have the latest 2.81 hardware and it doesn't work
It shows "FPGA configuration err!" and I believe it's because the memory layout needs to be changed.

Would it be possible for the firmware to be adjusted for newest hardware ?

Thanks