Any chances of building on 64kB Chip? (FNIRSI/CH32F103 compatibility)

[systematiccaos]

Hi,

first of all - I love this project! It really improves the UI and overall look and feel of the DSO. Do I have any chance to get it small enough to fit my STM32F103C8? With picolibc I manage to get it as low as 66kB. Do you have any idea how I could improve or compress anywhere?

[mean00]

Hi It barely fits in 64k with the following (DONT USE GIT head, use the release, the git one use bigger smoothed fonts)

• picolibc as you did
• change mcuSelect.cmake add SET( LN_MCU_EEPROM_SIZE 2 CACHE INTERNAL "") change SET(LN_MCU_FLASH_SIZE 64 CACHE INTERNAL "") SET(LN_SPEC "picolibc" CACHE INTERNAL "")
• edit src/dso_display.cpp comment out line 19 #include "assets/gfx/generated/splash_decl.h" comment out line 574 tft->drawHSBitmap(splash_width,splash_height,2,2, WHITE,BLACK,getSplash()); edit assets/CMakeLlists and remove the line gfx.cpp
• edit lnArduino/FreeRTOSConfig.h and change line 33 from

  define configASSERT(a) if(!(a)) {do_assert(#a);}

  to

  define configASSERT(a) if(!(a)) {do_assert("");}

It builds now within 64kB, not sure it works

[systematiccaos]

Oh wow, thank you for this very fast answer! Actually building and flashing worked, but it is stuck on calibration (not yet sure if it is because of not detecting the button press or really frozen). Anyhow, thank you!

[mean00]

If it is stuck at the end of calibration (i.e. when saving the values to flash) just retry It may work the 2nd time

[systematiccaos]

Actually it is not starting calibration, so it is stuck on the beginning.

[mean00]

Let me have a deeper look, i'll keep you posted

[mean00]

Does the attached binary work for you ? (it is ok for me, but the unit have more than 64kB of flash) You'll have to do the calibration twice, it will fail the first time lnDSO_M3_mod_hstep_72M_64k.elf.gz

[systematiccaos]

Thanks - does not work either. Still the same - I start the unit and it gets stuck on "Connect the probe to ground and press ok". Maybe there's something wrong with my buttons, but I don't think so, because they worked on the genuine firmware.

[systematiccaos]

BTW - where can I get you a coffee? ;-)

[mean00]

Thanks Are you stuck on the message "Connect the 2 crocs and press ok" ? Just in case, the ok button is the one on the right, not the rotary encoder

[systematiccaos]

The message is: "Connect the probe to ground and press ok". I pressed the correct button. :-) Already also tried the otherones.

[mean00]

if you can connect a swd debugger i'd be interested in having the backtrack

[systematiccaos]

I have a STLink v2 attached to it via SWD, so that would be theoretically possible. What kind of backtracking do you need? I am currently not able to step through the program. If you can tell me how to setup debugging, I might also be able to get some steps further on my own and be able to report back to you then.

[mean00]

In short, you need to start pyOcd for example, have a arm aware gdb then do something like arm-none-eabi-gdb target extended-remote :3333 load xxxxxx.elf mon reset b deadEnd r

If it crashes, it should stop at deadEnd If not, do until it stop responding and then CTRL+C and "bt"

[mean00]

pyOcd should detect the stlinkv2 automatically, no configuration needed i think

[mean00]

BTW, i suspect your chip is not a STM32F103, 99% of them have 128 kB of flash even if they only report 64 kB Maybe a remarked CH32F103 ?

[systematiccaos]

Thanks for your help! I just did the steps and it does not seem to crash. So maybe the issue is really related to the button-inputs or sth.

Reading symbols from lnDSO_M3_mod_hstep_72M.elf... Note: automatically using hardware breakpoints for read-only addresses. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/caos/workspace/lnDSO150/build/lnDSO_M3_mod_hstep_72M.elf

[systematiccaos]

You are right indeed, it appears to be a CH32F103 after looking closer to the hardware. They seem to have even remarked the chip on the hardware, but so badly you can still see the original markings... Holy crow....

[systematiccaos]

Ok, I just removed the calibration on start and can now confirm that the firmware is not stuck but buttons "ok" and "trigger" do not work on this particular board. The encoder is also not working (wired to pb14 + pb15).

[mean00]

i bought a ch32 based bluepill on amazon, it may help.

[systematiccaos]

I bought the original oscilloscope kit now - may help too. But would really love to make this work. I think I will tinker around with it on the weekend again.

[mean00]

The portB bus is shared between the screen and the keys. As a result the code is NOT using interrupts for key presses but poll the GPIO every 10ms or so. (i.e. take the bus, read value, releases the bus for the screen to use) So it is probably just a small difference around the GPIOS management Google translate did manage to translate the CH103 pdf from chinese to english

[mean00]

So the CH103 i bought turned out to be a genuine STM3F103 You cannot even trust the fakers nowadays

[mean00]

I added an option on git/head so you dont have to change anything cmake -DUSE_SMALLFOOTPRINT=True .. It uses 98% of the flash but it fits (still double check mcuSelect is set to arm/cortex m3, i change it often)

[systematiccaos]

Thank you - I will try this later.

[mean00]

Hi I've received the real CH32F103 bluepill boards Are you 100% sure the problem is not coming from the flash ? The GPIO seems to be 100% the same as the STM32 / GD32 chips, but the flash programming IS different

[mean00]

Bought a DSO150 clone, the bottom line problem is that they connected the "OK" and "Trigger" button to other pins That's why the "Ok" button was not working.

[mean00]

Building with -DUSE_SMALLFOOTPRINT and -DUSE_FNIRSI_BUTTON yields a working binary for the FNIRSI style clones

[mean00]

Prebuilt binaries available here : https://github.com/mean00/lnDSO150/issues/3