Just bought a couple of NodeMCU from vendor on AliExpress. They were advertised as "v2" and having 4M flash.
How can I verify the flash size? The board says "Ver 0.1", but don't know if that means anything.
You have basically two options: install a firmware (NodeMCU, Arduino, etc.) and use their functions or extract the flash ID and look it up.
Install NodeMCU
Build and flash the NodeMCU firmware.
Run print(node.flashsize())
Chip ID
install esptool.py
run esptool.py -p <serial-port> flash_id (gives you a hex manufacturer & chip ID)
look up the chip in https://review.coreboot.org/plugins/gitiles/flashrom/+/refs/heads/master/include/flashchips.h
As Marcel Stor said before in this comment, the esptool.py may be used to find the flash size.
Just run python esptool.py -p <serial_port> flash_id
Flash size is output like this Detected flash size: xx
Output sample
Related
Since I cannot get the manifold 2 in my region, I created a cable according to https://forum.dji.com/forum.php?mod=viewthread&tid=219723.
The cable is connected via FTDI converter directly to the drone's OSDK port.
when connected to a serial terminal application I get data from the drone
Terminal
When I try to debug the flightcontrol-sample in Linux, I get the following:
LinuxOutput
Data is also received in Linux using 'screen' command.
testing the cable for 'loopback' works fine.
I have changed the port baud rate to several options (230400 & 921600) to no avail.
the ACM cable is connected through an additional USB port to the drone's port directly.
Am I missing some HW components in my setup?
I have entered all the relevant Linux commands to get the required permissions as advised in
https://developer.dji.com/onboard-sdk/documentation/quickstart/development-environment.html
&
https://developer.dji.com/onboard-sdk/documentation/quickstart/run-the-sample.html
Am I missing something in that department?
The final goal is to use STM32 as FC, but testing is easier using the Linux environment.
Any additional things I can test?
Are there other working setup designs I can try?
Thanks for your help.
i got M300 osdk connection up at Apr 2020.
So far not many issues. There are many tricks and rules that you need to follows e.g osdk adapter board usb type C seam side face inside. make sure osdk adapter board is powered up by checking the output supply voltage. 3.3V FTDI. and make sure it is pull up properly by checking voltage as well
After you check through the hardware.
the software has many tricks as well. for M300 only osdk/osdkros 4.0 and above can drive. The new userconfig.txt format changed and you have to change accordingly. and you can go through my checklist which I posted on DJI forum https://forum.dji.com/forum.php?mod=viewthread&tid=216529
If you really still have a problem. do provide photos on your connection, the terminal output for the error message.
As Dr. Yuan suggested, have a look at the UserConfig.txt file. Depending on which OSDK version you are using, it has a different format.
In my case, using osdk 3.9 configuring it this way solved my issues:
app_id : xxx (number)
app_key : xxx (number)
device : /dev/ttyUSB0
baudrate : 230400
Also check your FTDI cable, it once burned out for me and it was the reason for this error too. You should try a new one just in case.
I use the OSDK with a raspberry pi, in case you are using this kind of linux environment, I suggest you check the configuration files (cmdline.txt and config.txt) doing sudo nano /boot/cmdline.txt and same for config.txt.
my configuration for cmdline.txt is:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
And for config.txt just add this at the end:
enable_uart=1
init_uart_clock=64000000
start_x=1
I hope these can help and that I am not too late.
I am currently setting up a microcontroller with several libraries which need to be built from source. Using pre-built binaries is not an option due to the system architecture. Building dependencies takes a lot of time and I want to avoid having to do it again for every similar device I need to setup in the future.
Thus, my question is, how can I migrate custom built binaries to another machine of similar architecture?
Any solution that would mirror the whole system to another drive works, too.
Note: For my current use case I am running Ubuntu 18.04 off a MicroSD plugged into a Jetson Nano
Any solution that would mirror the whole system to another drive works, too.
Proposed Solution :
Create a backup of the MicroSD card which has all required binaries installed
Use the backup to mirror the stuff into different MicroSD cards.
Backing Up Your SD card
Connect the SDcard to your laptop
Use dd command to take a backup of your MicroSD card
sudo dd if=/dev/sdxx of=backup.img status=progress
Restoring your backup to a New SD Card
Connect the New SDcard to your laptop
Use dd command to restore the backup to New MicroSD card
sudo dd if=backup.img of=/dev/sdxx status=progress
Note: Your SD card may also show up as /dev/mmcxx or /dev/sdxx depending on how you connect it to your laptop.
Warning: While running dd command, Please make sure that /dev/sdxx is your SD card and not your Hard Disk.
Running this command will tell you the device name of your SD card.
sudo fdisk -l
Please refer to this link for more.
Finally the sparkfun board edge boards arrived today ;-)
Following this well written guide : https://codelabs.developers.google.com/codelabs/sparkfun-tensorflow/#3 i am stuck with the following NoResponseError when trying to flash the code on the Ambiq, with the uart_wired_update.pyscript, that comes with tensorflow examples
opprud$ python3 tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py -b 115200 /dev/cu.usbserial-1430 -r 1 -f main_nonsecure_wire.bin -i 6
MOJ/Connecting with Corvette over serial port /dev/cu.usbserial-1430...
Sending Hello.
No response for command 0x00000000
Traceback (most recent call last):
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 336, in <module>
main()
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 38, in main
connect_device(ser)
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 58, in connect_device
response = send_command(hello, 88, ser)
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 235, in send_command
raise NoResponseError
__main__.NoResponseError
My setup:
Macbook pro, tried both old 15" & new 13"
Sparkfun serial basic breakout, USBC version (default jumped to 3v3)
FTDI 3v3 serial cable
I have tried
two different edge boards, with the correct Key14 & reset combo + misc variants and timing
legacy USB on old Macbook
new Macbook w USB C
FTDI 3v3 serial cable as alternative to sparkfun serial board
Running an alternative uart_boot_host.py script in tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/bootloader_scripts/uart_boot_host.py, also no response
I can measure, with a scope, the handshake bytes '0x14', '0x55', '0x9d', '0xe9' '0x0', '0x0', '0x8', '0x0' being transmitted initially at 115200 on the TXO pin on the programming header - but the ambiq is not replying anything.
btw. The onboard demo is running, blue led flashing, an some "yes's" are being recognized.
Any inputs welcome.
Does anyone know the protocol for the corvette bootloader ?
Are there any CPU revision changes from the first batch of boards, or possibly any lock bits programmed accidentally from sparkfun ?
rgds from an eager TF lite user ;-)
I tried measuring the actual baudrate with a scope on rx/tx pins, and saw that the bit timing using default OSX serial driver is rather imprecise, app 10% off, causing faulty readings, and ultimately missing bytes, when the baudrate are high.
After updating to the ch340 serial driver, timing improved, and the bit timings were correct.
At 921600bps, a single byte 8N1 is supposed to be10.9uS
Driver install
https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver
This is what worked for me: (source: github.com/sparkfun/SparkFun_Edge_BSP/issues/3, the SparkFunEdge tutorial and my teammates!). I am running this on a Linux machine (x86_64; Run $ uname -a) and my SparkfunEdge DEVICENAME=/dev/ttyUSB0
The tutorial does warn you about this problem at Step 4:
Note: Some users have reported issues with their operating system's
default drivers for programmer, so we recommend installing the
driver before you continue.
Click on the driver link and follow the instructions under "Other Linux distributions" as follows:
Install the correct version of the ch34 library.
$ git clone https://github.com/juliagoda/CH341SER.git
$ cd CH341SER/
$ make
$ sudo insmod ch34x.ko
$ sudo rmmod ch341
To verify that the correct driver is being used, run:
$ dmesg
..
[889247.585301] usb 1-7: ch341-uart converter now attached to ttyUSB0
[955698.718839] usbcore: registered new interface driver ch34x
[955698.718848] usbserial: USB Serial support registered for ch34x
[955759.196437] usbserial: USB Serial deregistering driver ch341-uart
[955759.196576] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[955759.196601] usbcore: deregistering interface driver ch341
[955759.196643] ch341 1-7:1.0: device disconnected
Now unplug the USB-C from the SparkfunEdge Board, and plug it back again
$ dmesg
....
[955876.176950] ch34x 1-7:1.0: ch34x converter detected
[955876.177320] usb 1-7: ch34x converter now attached to ttyUSB0
glad to hear that you're so excited about the board. I have a hunch that this will be an easy fix.
The Edge boards handed out at the conference have a bootloader set for 115200 baud, however the Edge boards that have come out in the second batch are upgraded to flash at 921600 baud, greatly reducing flashing time. Try changing the baud rate in your serial upload script.
You can also set up the Ambiq Software Development Kit to write your own applications for the Apollo3 microcontroller. Check out the tutorial here: Using the Edge Board with Ambiq SDK
Since I can't comment on your post (not enough reputation.... thanks SE) I'll be responding here.
If the baud rate accuracy is a problem I'm slightly unsure that that would be caused by the OS, but rather I'd think it is a problem with the USB-serial converter chip. I've been using the CH340G whereas on the USB-C version there is the CH340C IC. The difference between the two is that the "C" version includes an internal oscillator to provide the frequency reference. It is possible that that one is less accurate...? I'll try it out over here (but on windows) and let you know.
If this is a persisting problem would you mind making a post on the SparkFun forums? That way our tech support can get linked in (they are the people who could get you replacement hardware in case it is defective, also). Here's a forum for the Edge: SparkFun Edge Forums
If the problem is coming from the OS then the only fix that we can do with the Edge is to reduce the bootloader speed. We're working on a short tutorial about how to do that, but it would require having a programmer/debugger for Cortex-M processors. The Ambiq Apollo3 Evaluation Board has a built-in SEGGER J-Link which is what we used to program the boards.
On MacOS Mojave, Installing/Reinstalling CH340 works for me:
https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers#mac-osx
Before doing install, check that you actually see the sparkfun edge device with:
ls -l /dev/cu*
If driver is correctly installed, you should detect:
/dev/cu.wchusbserial1420
I got similar issue whereas I only had /dev/cu.usbserial-1420 and thought that was expected device to access, whereas it is /dev/cu.wchusbserial1420 which was only detected after installed ch340 driver.
Then flashing device works successfully for me.
Is it possible to have a named pipe on my PS side of the Zedboard; that leads to a FIFO in the the PL side (using DMA,AXI,I2S etc) that I then revert to the audio out port and play songs from my PS side and listen from the audio out port on the PL side?
If yes then what steps are to be followed on the PS Side?
I'm guessing at mapping of user space into kernel space.
Yes, it turns out that ANALOG DEVICES has just the stuff you need.
There is a different kernel that Analog Device's maintains, which
includes both ALSA drivers
for the audio chip (ADAU1761) and the HDMI output (ADV7511).
https://github.com/analogdevicesinc/linux
there are a few zynq branches in there. Normally Xilinx pulls drivers
from there for their kernels,
but anyone can do the same.
The build instructions (if that's the sort of thing you want to do) is
at:
http://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/software/linux/zynq_2014r2
Or, alternatively you could just download the ready-made image for your particular board from this dropbox link:
https://www.dropbox.com/sh/yfbpj63pcenqatr/AAAt0s3xFXs47I7q5pNopheHa?dl=0
After you download the file; uncompress it with this command:
unxz -d sdimage-8G-zedboard.direct.xz
Find out the name of your SD Card with this command:
dmesg|tail
And then write the resulting image to your 8GB SD Card with this command:
sudo dd if=sdimage-8G-zedboard.direct of=/dev/sdX
where sdX is your particular SDCard which you noted from command dmesg|tail
This command will erase all the pre-existing data on the sd card so make sure you have a backup if that data is important to you.
WARNING: Please be VERY careful while using the dd command. Writing the image to the wrong /dev/sdX location could possibly lead to corruption of OS and/or the hardware also and is extremely risky.
After you burn the image; you're good to go! A full-blown graphical linux environment will turn up ( You need to connect an HDMI display; and use USB OTG port to use the mouse and keyboard)
NOTE: You can also choose between what path you want your sound to play;
whether from the headphone jack or through the HDMI cable.
Background info
WinAVR:
I installed WinAVR, and use avrdude.exe comes with WinAVR to download program into our board.
Adapter card:
We have an adapter card with FTDI4232 and AVR m328p on it. PC connects to FTDI4232 with a micro USB cable.
Schematic:
Sorry, I cannot post pics. So just describe the major part of schematic here. Two wires from(DATA_P & DATA_N pins) out from macro USB connector to DP[pin8] and DM[pin7] on 4232. And four wires(SCK, MOSI, MISO, SS_N) out from 4232 to m328p.
How to download program into the card before: Via pocket programmer. But we cannot give one pocket programmer to every engineer, so try to find out a way to download the program into m328p. Coz we have already had FTDI4232 on board, so this seems to be the best choice.
Can I download program via FTDI4232 on adapter card?
I know there is dedicated programmer based on 4232 chip, but this is our own design, I am not sure we can do it or not according to the above schematic.
what I did
Run this command:
C:\WinAVR-20100110\bin\avrdude.exe -c 4232h -p m328p -U flash:w:\Desktop\work\a_card\WinAVR\blink\blink.hex:i
But got the following error:
avrdude.exe: Error: no libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again.
Then, download the compiled libftdi package from this link:
https://code.google.com/p/picusb/downloads/detail?name=libftdi1-1.0_devkit_mingw32_17Feb2013.zip
, and extract it as “compiled_libftdi”.
There is not too much info about how to use this compiled package, so I just found info online.
(1) I installed WinUSB driver for the first two ports of 4232 by Zadig. I can choose one port in the drop down menu, then choose “WinUSB(v6.1,7600…)”, “Install WCID Driver”.
(2) Then, enter into the “compiled_libftdi” folder, run “find_all”, I saw:
Number of FTDI devices found:1
Checking device: 0
Manufactureer: FTDI, Description: USB <-> Serial Converter
I think it means the USB driver for libftdi package installed successfully.
Run the above download command again, still failed.
I thought maybe because the avrdude.exe is out of date. So download a .exe from here:
http://download.savannah.gnu.org/releases/avrdude/avrdude-6.0.1-mingw32.zip
And replace the old one in the WinAVR folder.
Still got the error, but got one extra line info:
avrdude.exe: programmer operation not supported