Command line for ESP32 burning - esp32

I tried to burn it from my GUI (C#) by invoking it from ShellExecute
Arduino15\packages\esp32\tools\esptool_py\3.0.0/esptool.exe" --chip esp32 elf2image --flash_mode dio --flash_freq 80m --flash_size 4MB -o "main.ino.bin" "main.ino.elf"
Actually it burns but something goes wrong and program doesn't run.
So I go to a build folder - load main.ino.partitions.bin at address 0x8000 and
main.ino.bin at address 0x10000 with flash_download_tool_3.9.2.exe.
It's burned successfully however program doesn't run. What part do I miss? Why Arduino IDE knows to burn it right and I fail?

Related

ESP32 WROVER-B programming issue

trying to program ESP32-WROVER-B it stops just after start, I have connected button EN (on pin EN) and tried various combinations but it didn't help.
Also tried to change baudrate, fix flash size to 4MB but still nothing.
This is the output:
$ make -j4 flash monitor
Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5
Compiler version: 5.2.0
App "websocket_server" version: b4b6984-dirty
Python requirements from C:/ESP32/esp-idf/requirements.txt are satisfied.
Flashing binaries to serial port COM8 (app at offset 0x10000)...
esptool.py v2.6-beta1
Serial port COM8
Connecting........_____..
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 24:6f:28:4c:9b:4c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 230400
Changed.
Configuring flash size...
Compressed 24240 bytes to 14517...
Wrote 24240 bytes (14517 compressed) at 0x00001000 in 0.7 seconds (effective 295.4 kbit/s)...
A fatal error occurred: Timed out waiting for packet header
make: *** [/c/ESP32/esp-idf/components/esptool_py/Makefile.projbuild:63: flash] Error 2
Any hint?
In case your ESP32 looks like this one you need to keep pressed the RST button while uploading the new code to avoid that error.
Hope this helps you!

Programming an Attiny85

I was wondering how to upload a program I wrote using AVR Studio 4 to an ATtiny85. I was basically using this tutorial http://blog.smileymicros.com/smileys-workshop-10-moving-beyond-arduino/ except doing everything with an attiny85 instead of an atmega328. I got the pins_arduino.h from HighLow tech's ATtiny library.
I have compiled successfully in AVR Studio 4 and am now wondering how to upload to an Attiny85.
Thanks
Download the Windows-Avrdude version: http://www.mikrocontroller.net/attachment/69851/avrdude-5.10.zip
Extract the avrdude.exe files (avrdude.conf and avrdude.exe anywhere in your directories.
Now in AVR Studio, create a new tool under external tools (don't know exactly if it is called external tools) and call it 'ATtiny85'.
Paste this line in the command field: C:\Path\To\Your\avrdude.exe.
Paste this in 'Arguments': -F -v -pt85 -cstk500v1 -P com7 -b19200 -Uflash:w:"$(ProjectDir)Debug\$(ItemFileName).hex":i -C
Make sure you replace 'com7' with your com port you've attached your avrisp mkii to.
Now finish the dialog and your ready to upload. (Just click your tool in the Menu)

Falied to register i2c-dev module

I'm trying to run some i2c testcases for ltp-ddt on arm board.
I installed i2c-tools, i checked i2c devices in /dev folder,
$ls /dev/i2c-*
/dev/i2c-0 /dev/i2c-1 /dev/i2c-2 /dev/i2c-3.
But, when i try to detect i2c devices by running
$i2cdetect -a 0
its throwing error as,
Error: Could not open file `/dev/i2c-0': No such device or address
Please let me know the valid solution ASAP.

Linux debugging with Jtag - [ARM9][AT91SAM9G25] - Amontec, openocd, gdb, eclipse

I'm trying to start kernel debugging with this sytem:
Amontec JTAGkey2, openocd, gdb, eclipse.
At the end I would like to debug kernel and application that is running within.
I have few problems, and it seems that I need to solve them sequently.
Now I have CPU suspend/resume, read/write RAM
What is missing: Step into, Step over, C/C++ Level debugging.
I do following:
- Connect JTAG, Power up board, start uImage with Debug messages via Uboot
- start openocd:
# openocd -f /usr/share/openocd/scripts/interface/jtagkey2.cfg -f /usr/share/openocd/scripts/board/at91sam9g20-ek.cfg
Output:
jtag_nsrst_delay: 200
jtag_ntrst_delay: 200
RCLK - adaptive
TapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr
---|--------------------|---------|------------|------------|------|------|------|---------
0 | at91sam9g20.cpu | Y | 0x00000000 | 0x0792603f | 0x04 | 0x01 | 0x0f | 0x0f
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
Info : JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0)
Info : Embedded ICE version 6
And problems starts here:
openocd:
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Warn : target not halted
eclipse:
symbol-file /opt/Tixi_Repos/KiwiG6v2/buildroot-2011.05/package_tixi/linux-2.6.39/arch/arm/boot/compressed/vmlinux
target remote localhost:3333
start () at arch/arm/boot/compressed/head.S:108
108 kphex r5, 8 /* end of kernel */
It seems also that JTAG is trying to load the code into 0x0, what is incorrect I suppose:
Update 1:
After analyzing some online tutorials for ARM:
Eclipse Reset and Halt commands doesn't work perfect. It is better to uncheck them and write into command window. Also load address can be add:
monitor halt
load arch/arm/boot/compressed/vmlinux 0x22000000
I don't use
monitor reset
I let Uboot start and initialize RAM and other peripherals. Then I stop Uboot by getting into shell. Then I let eclipse write linux into RAM, and start it. It takes very long, but works bit better. Kernel starts and stopps on RPC initialization without giving console back.
would it be possible to load kernel into RAM within Uboot console, and start JTAG session afterwards ?
What is the difference between [load ...] and [monitor load...] commands
Why do I need to load /compressed/vmlinux instead of uImage ?
in eclipse window I have two load fields: load image i load symbol. I disable both options but write only load arch/arm/boot/compressed/vmlinux 0x22000000. Is it maybe the reason for next problems ?
Update 2:
Ok. Thank you for hints.
I've made some progress. Could you give me some advices, maybe I'm still doing something wrong.
Now my kernel runs under JTAG control, but I still can't debug on source code level.
I do as follows:
Power up the board, go into uboot shell.
start openOCD session
Set Uboot breakpoint in bootm.c on theKernel call:
cleanup_before_linux ();
theKernel (0, machid, bd->bi_boot_params);
start eclipse debug session :
monitor halt
load uboot-a without offset
load u-boot-2010.06/u-boot
Loading section .text, size 0x349ec lma 0x26f00000
start uboot and let it run
uboot stopps on "theKernel" call
I know that kernel is located on address 0x20008000.
restart openOCD session
start ecipse debugger once more with kernel configuration:
monitor halt
load kernel on address 0x20008000
load arch/arm/boot/compressed/vmlinux 0x20008000
Loading section .text, size 0x8bdc7c lma 0x20008000
start debugg session
Everything works fine now, and kernel starts, but I still can't debug on source code level.
"symbol is not available"
DEBUG and DEBUG_INFO are on for kernel.
vmlinux screenshot
What seems starnge for me that there are around 50 function symbols in this file.

Debug Linux kernel pre-decompression stage

I am trying to use GDB to debug a Linux kernel zImage before it is decompressed. The kernel is running on an ARM target and I have a JTAG debugger connected to it with a GDB server stub. The target has to load a boot loader. The boot loader reads the kernel image from flash and puts it in RAM at 0x20008000, then branches to that location.
I have started GDB and connected to the remote target, then I use GDB's add-symbol-file command like so:
add-symbol-file arch/arm/boot/compressed/vmlinux 0x20008000 -readnow
When I set a breakpoint for that address, it does trap at the correct place - right when it branches to the kernel. However, GDB shows the wrong line from the source of arch/arm/boot/compressed/head.S. It's 4 lines behind. How can I fix this?
I also have tried adding the -s section addr option to add-symbol-file with -s .start 0x20008000; this results in exactly the same problem.
There are assembler macros that print out stuff when compiling with low level debug. You have to make sure the macros are appropriate for your board.
linux-latest/arch/arm$ find . -name debug-macro.S | wc
56 56 2306
Find the file for your board and ensure the correct serial port registers are hit. You can instrument the code with out using JTAG. These macros are used in the decompress code. Of course configure with *CONFIG_DEBUG_LL*.
Most likely the ATAGs are not correct or one of the other requirements. Checkout Documentation/arm/Booting to make sure you have registers set properly. Note there is a new requirement with recent kernels to send a dt list.

Resources