Loading of .hex firmware files fails using any O/S on LA104 with Device firmware V3.61D about la104 HOT 11 CLOSED

Great! I am glad you made it. The official release is pretty outdated. You are probably the first tester of LA104 package :)

In the mini release, there are following applications (but without graphical shell):

• shell.elf - simple file manager
• 15charla.elf - character map
• 17analys.elf - original LA104 analyser application
• 21mplayl.elf - midi player (connect P1 and VCC to midi socket, one midi file included)
• 2import.elf - just simplest application, draws sierpinski triangle
• 33temper.elf - DS1820 temperature grapher (connect sensors to P1)
• 37icscan.elf - I2C scanner with database of most common i2c devices (P1 & P2 - sda/scl)
• 39lcd.elf - LCD scrolling test
• 49gpio.elf - simple 8 signal logic level analyser + generator + PWM
• 61devin.elf - shows device information
• 63ws_la.elf - addressable led tester (WS2812 RGB/RGBW)
• viewtxt.elf - text file viewer (select the file in shell with fourth button before running)

For what purpose you want to use the LA104?

If you will find out any valuable information regarding firmware upload, please drop it here so others could learn from it if they will be facing similar problems. I use only the dfutool on mac all the time without any problems...

from la104.

Forgot to mention I also tried various Linux O/S as well as Windows XP and Windows 98 since I have live boot disks for them lol :-)

from la104.

if you have linux/mac machine available, could you please try to upload the firmware using dfuload tool? https://github.com/gabonator/LA104/tree/master/tools/dfuload

from la104.

Hi Gab, Yes I did use the dfuload tool which I grabbed via git clone and built on a Linux Mint (Mate 64bit X86) 19.2. It appeared to copy in that it reported success and copied a number of blocks, yet the LA104 placed a file such as system.err or system_la104.err on it's filesystem.

I didn't try to use the format command, as I'm not sure of the necessity to do that since there are several hidden files that appear on Fat12 drive.
I don't have access to a Macbook or Mac O/S we had a battle with Mac and the O/S many years ago and removed it.

BTW if you haven't already, have a look at the new STM32 CubeIDE, if you don't mind eclipse based IDE, then you'll find it's pretty good.

from la104.

Please try following build: (la104.hex is the firmware that needs to be flashed)
https://github.com/gabonator/LA104/releases/tag/2020.1.mini

It is just fresh build of the OS for LA104, but the load/entry address is the same, so there is only little chance that it will work. If the problem is related to the firmware size (if copy fails at specific file position) I can prepare build without USB support which should be much smaller. Did you try to upload the firmware from different computer? Or just different virtual machines on the same PC?

My device shows the same DFU version V3.61D, so we should have identical devices.
Formatting won't help, the DFU is only emulated disk and the formatting command is for clearing the eeprom when it is fragmented too much.

from la104.

Hi Gab,
Success with the release/tag/2020.1.mini - although I'm going to experiment a bit as I think some of the issue is due to confusing between various errors because although I had success getting your O/S to run etc there was some oddness,
For example when copying the la104.hex file, Windows 10 dropped the file transfer giving the impression of a fail. Then when I rebooted the LA104 it displayed a message saying that the shell.elf was missing which indicated that I was running and just need those files.
I then went back to your official release and redid the same steps whilst already having copied the matching apps directory tree and the shell.elf, fileman.elf and viewtxtl.elf onto the normal file system that the LA104 presents (not the special boot system).

from la104.

My purpose for the LA104 is primarily for assisting with i2c development. My work revolves around what is now labelled the new buzz word - IOT (Interntet of Things) although I've been working in that field for over 20 years and protocols for 40 years.
At this moment I've got a project on my desk that uses STM32 micros as well an ESP32. Altlhough my office has over 20 different micro controller types but the common element is always RS232, I2c and SPI. I do have a few larger protocol analysers but they take up desk space and only need them when I'm tracking down some weird problem or reverse engineering something. So the LA104 is a nice little gadget that can use to do a quick check on the i2c bus of some of these projects.
Plus with your software it could allow me to do a i2c bus scan and check if a device is responding appropriately.
At this moment I've created a merged build of the LA104 software that has combined your GNU version with Ralim (another Github person) variant. As I liked his modifications to the controls.
My goal is to then move that over to the STM32cube environment and put it back on Github.
One of the modifications I need to do to the LA104 is add an option for how it displays the i2c address as it shows it as literal (raw) which is in fact left shifted, so I'd like to shift the address byte right.

I also need some information about what has to be done to generate a ".elf" file compatible with your O/S.
When I created my own LA104.hex file I could flash it and work okay, but if I stripped it with the elf strip utility and dropped it into a folder for your O/S to manage it seemed to be trying to load and flash the file at 0x0000 and would freeze.

Finally I'm also doing some hobby stuff with the WS2812b strip leds and was hoping to test them with your 63ws_la utility for fun :-) I've started building an MQTT controlled strip light sequencer where the MQTT commands allow me to control and syncronise a number of RPI or ESP32 light controllers.

from la104.

Seems that LA104 will perfectly fit your needs. You have already set up your building environment? With the original analyzer firmware there was an issue with the RAM memory - it uses too much RAM and it couldn't fit in my OS, so I had to reduce the size of some buffers in it.

Here is the source modified for use in my OS:
https://github.com/gabonator/LA104/tree/master/system/apps/test17_official

all changes are marked with "gabo" comment, see AppBios.h, the buffer size (RECORD_DEPTH) was initially 3584 and I had to reduce it to 500 to fit in RAM. There are still many options how to optimize the RAM usage of OS, but for testing it just worked.

For building, there is shell script build.sh, and very important file is the linker script file (app.lds), it defines the memory (ram/rom) ranges where the firmware is placed. @fredzo made a nice tutorial how to setup the building environment for windows: https://github.com/gabonator/LA104/tree/master/system/os_platform/win32_sdl

from la104.

Excellent :-) I'll see if I can create a merge of that with conditionals and the Ralim merge that I've done, so that I'll have the best of all worlds.
I won't be able to start for awhile as I'm drowning in problems with FreeRTOS memory management along with the oddball CMSIS-RTOS wrappers that STMicro have encouraged.

from la104.

Hi Gab, I've created a merged build that builds on the STM32CubeIDE on Windows/Mac etc.
See https://github.com/MarkOliver1959/LA104
It's not yet able to run on your O/S. It took long enough to get into that code and make it link properly on the IDE.
I've added some comments to the LA104 code that maybe useful and started some merging to prepare it for you O/S.

from la104.

@exabrial, it's ok. I it does the same on my mac. The firmware should be flashed properly even when the tool does not finish correctly.

from la104.