I have an issue with spiffs and arduino.
I'm using ESP07 with 1mbyte of spi flash memory. I'm using arduino IDE.
I have 16 files in my file system being sketched with the option "tools -> ESP8266 Sketch data upload". If i selected 256kbytes as SPIFFS size all works fine. All files are there and the system works fine.
But if I use 512 kbytes for SPIFFS only 8 files are there after using the same "tools -> ESP8266 Sketch data upload" option.
I have verified my flash spi memory with the demo included in arduino IDE "CheckFlashConfig", it is 1mbyte.
I need to use the 512 kbytes model because the customer can upload a file that can be too big for 256kb spiffs model.
As curious stuff, I selected 2 mbytes (even when memory is 1mbyte), asigning 1.5mb/512kbspiffs and it worked fine (probably because the last bit address was ignored and it worked over 1mbyte really doing it 512/512).
I have the option to upload all those files manually and it will probably work but it is slower than just burn the memory in production.
Is it a SPIFFS bug? a problem with spiffs in arduino o maybe something that i'm missing?
Thanks.
NOTE: I'm using esp8266 community version 2.5.0 package
Since I am not allowed to comment:
Please upgrade to ESP8266 v2.6.3:
The SPIFFS as standard file system has been replaced by LittleFS (means small changes in code if using the DIR opject), but offers improvements in regard to reliability.
For testing choose Generic ESP8266 with this params 1MB (FS:512KB OTA:~246KB)
If the problem (unlikely) persists or you dont nred OTA check the partition schemes in
the following boards.txt
C:\Users\YOURUSERNAME\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\X.X.X\
dependingon theversion can be 2.5.0 or 2.6.3
- you can define your custom scheme if you like
Related
For all of these scenarios, I am able to upload the firmware and monitor via serial usb. But after creating my first firmware, for all new firmware, I can't upload Lua scripts using the nodemcu-tool without getting the following:
Error Message
F:\Development\NodeMCU\helloworld>nodemcu-tool -p COM3 upload init.lua
[NodeMCU-Tool]~ Unable to establish connection
[NodeMCU-Tool]~ Invalid node.chipid() Response: 6935962
Observations
Can reset the board using nodemcu-tool. Leads me to assume the baud rate is fine.
Can see the file system being created from PuTTy after loading any of the firmware. Leads me to assume the firmware is OK.
Have tried multiple dev boards, same results
Found the source of the error message device-info.js. either line 45 or 49
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
A new commit was made to the firmware source during the last couple of days. No idea if this is relevant.
Was hoping to get this resolved before I go down the Docker rabbit hole. Lazy. I know.
9/6/2019 - created first firmware to start development
Built a firmware using https://nodemcu-build.com/ with these modules (cron, file, gpio, i2c, mdns, mqtt, net, node, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
No issues with this firmware. I've been able to upload lua scripts and test them successfully. Even now, I can revert back to this firmware and use it without issues. I've even redownloaded this firmware from the original link, and it works fine.
9/7/2019 - created a new firmware to use adc and other goodies
Built a firmware using https://nodemcu-build.com/ with these modules (adc, cron, file, gpio, i2c, mdns, mqtt, net, node, rtctime, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
9/8/2019 - built firmware with minimal modules
Built a firmware using https://nodemcu-build.com/ with these modules (file, gpio, net, node, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
Platform & Tools
Windows 10
Development board: HiLetgo ESP8266 NodeMCU LUA CP2102 ESP-12E Internet WiFi Development Board Open Source Serial Wireless Module
Firmware builder: https://nodemcu-build.com/
Serial Monitor: PuTTy 0.72
Firmware Loader: NodeMCUPyFlasher 4.0
Lua script loader: nodemcu-tool 3.0.2
fetchDeviceInfo() first calls node.info() at https://github.com/AndiDittrich/NodeMCU-Tool/blob/master/lib/connector/device-info.js#L9. Then it does an if-else to figure out whether it's running on ESP8266 or ESP32.
With the recent upgrade to SDK 3.0 node.info() was changed in PR #2830. See documentation at https://nodemcu.readthedocs.io/en/latest/modules/node/#nodeinfo. It now returns values the script doesn't consider to be coming from ESP8266. The script then calls node.chipId() in the else branch. So, it's getting a chip id from ESP8266 but it is expecting one from ESP32. Hence, the exception.
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
It's your chip id.
To cut a long story short: NodeMCU-Tool needs to be adjusted as laid out above to work with the current NodeMCU version.
I cached the same issue from the recent cloud build(https://nodemcu-build.com/). It works when i switch back to the old ones. It looks like a problem of the build system or recent source code. You can switch to other build method and try use the older code.
For development purposes I have been using the "NodeMCU Firmware Programmer" to flash the firmware to the ESP-12 NodeMCU Dev Kit V2, and then using ESPlorer to upload the lua files.
This works well for development purposes, but now we are moving into commercial production.
Is there a faster way (one-step?) to upload both the NodeMCU firmware and lua files? I need to program between 1-5k units per month.
Yes, there is a one-step way.
You first build a file system image using spiffsimg and then flash both the firmware and the image to the device (with esptool.py I suggest).
Apologies in advance for the dated software question:
According to Code Composer help documentation the "Memory Load/Save Utility" should be be in the Tools menu. In my Code Composer 3.3 (which I have to use for this project, so I cannot upgrade), does not have this option in the tools menu, or any menu that I could find. It is not greyed out - it is just simply missing as far as I can tell. I've changed every view option to try and enable this.
Can anyone help me figure out how to enable/activate this option? Does the processor need to be in a specific state? Is this a special plug-in that I can't find?
Here is my setup:
Code Composer 3.3, Windows Xp, Using a Spectrum Digital xds510pp JTAG emulator on a TI ARM 9 processor.
Specifically the option is here: 13. Memory Load/Save Utility:
http://www.ti.com/lit/an/spraa07c/spraa07c.pdf
[EDIT] The File > Data > Save - this is not the same as the Memory Load/Save Utility. This sounds similar but does not export the values.
For example, I need to export data at a certain memory address for a certain length into a hex format.
Somehow my installation went bad.
I checked the Code Composer Studio Component Manager by running C:\CodeComposer3.3\cc\bin\comp_mgr.exe. Now, in this window un the TI node, there should be numerous plugins and one of which should be: "Memory Save/Load Utility Control..."
For me this was missing.
Repairing the installation via windows control panel did not work. I had to uninstall and then reinstalled. Upon reinstalling a TMS470 driver was reported missing. Not sure why this was.
Again, I uninstalled then complete removed the C:\CodeComposer3.3\ directory, then reinstalled. This time everything seemed to have worked and I do have the Memory Save/Load Utility and it is working.
EDIT:
It should also be noted that the plugins are bundled with the installer and could not be re installed separately.
I wish to register some of status of my application as a performance object, so that I can monitor its performance by utilising the Windows Performance Monitor.
But I had a problem with Windows 7: the performance object cannot be seen in the list of Performance Monitor, even if my application is running.
My code is exactly the same as the Delphi project in this tutorial:
http://www.wehlou.com/Code/perfmon/index.htm
However, the solution provided in this tutorial doesn't work in Windows 7 either.
Such solution works fine in Windows XP and 2003.
I don't know if there are some changes in Windows 7 which makes my performance object missing.
Please help. Thanks a heap in advance.
Is your Windows 7 computer a 64-bits machine? You may have to provide both a 32 and 64 bits version:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371636(v=vs.85).aspx
The short answer:
Yes you can fix manually the 2 object performance counters (DeltaCount & RawCount) issue under Windows 7 x32. The 2 files generated by PerfMonClient.exe are usable (namely symfile.h and symfile.ini).
Nota: Refer to MSDN for the usage of lodctr.exe.
Prior to that an entry to the registry as follows should created:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PerfMonClient\Performance]
"Open"="PerfData_Open"
"Close"="PerfData_Close"
"Collect"="PerfData_Collect"
"Library"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,50,\
00,65,00,72,00,66,00,4d,00,6f,00,6e,00,44,00,4c,00,4c,00,2e,00,64,00,6c,00,\
6c,00,00,00
Nota: Library point to %SystemRoot%\System32\PerfMonDLL.dll (location of the performance DLL).
Any attempt to install and/or uninstall them using PerfMonClient.exe App doesn't work even under Windows XP. Forget about that.
Look an feel:
Listing
symfile.h:
#define OBJECT_1 0
#define DEVICE_COUNTER_1 2
#define DEVICE_COUNTER_2 4
symfile.ini:
[info]
drivername=PerfMonClient
symbolfile=symfile.h
[languages]
009=English
[text]
OBJECT_1_009_NAME=PerfMonTest Performance Counters
OBJECT_1_009_HELP=A demo application for your unbridled pleasure
DEVICE_COUNTER_1_009_NAME=RawCount
DEVICE_COUNTER_1_009_HELP=A count of something that goes up and down
DEVICE_COUNTER_2_009_NAME=DeltaCount
DEVICE_COUNTER_2_009_HELP=Something going up all the time, Windows shows difference per time unit
Is it Possible to create bootable (Applications for MBR )application using Delphi or Pascal (I know we cant use vcl , RTL and other stuffs because they depend on OS), but can i use at least Readln and writeln.
If it is true !!! Can we run the program under other OS.
but i know that PE (windows) and ELF (Linux ) formats are different. but at least with some small modification can i do it.
It's worth saying that PE is a very diverse format than ELF.
Not only a few bytes to modify... the whole layout and library access is diverse, and binding is totally diverse.
In order to boot Delphi application in console mode, you can put a small DOS system (take a look at FreeDOS, for instance), then run your Delphi application using for instance DWPL. DWPL allows to run native 32-bit protected mode DOS programs with Delphi 5-7 using the WDOSX DOS extender as the core. I used this in some old hardware with a network adapter, and it worked like a charm. If you are interested in it, I could post some updated code of DWPL.
For such targets, you should take a look at Free Pascal. By nature, you can customize it to whatever target you want. There is even diverse draft Operating Systems written using FPC. See for instance Toro or ClassiOS - the latest uses Delphi executables as source.
You can see the boot code of Toro from here, and a "main program" source code created with it.
But for direct booting applications, booting is not so difficult. The real problem is the hardware layer.
The BIOS gives very little access to it.
Just for the network layer, you'll have to take a look at EtherBoot sites and such to get some low-level network access... but it could be very time consuming to rewrite all those drivers by hand!
In short: all those "pure pascal" OS are only theoretical, running a console and some low-performance network (emulating a poor network adapter like NE2000 or such). So those "pascal" OS are only proof of concept. FAR away from a working solution! But very nice technological challenge, in all cases, very inspiring.
Why reinvent the wheel? If you want a light and fast system, use a custom Linux kernel.
Then use CrossKylix to compile your Delphi application (with no User Interface) into Linux, or even better Free Pascal.
You don't really place "applications" in the MBR.
The entire size of an MBR is 512 bytes, of which you can only use 446 for code.
Good luck creating something useful in that if you don't even have an OS to delegate functionality to yet. Basically all that you can do in the MBR is place code to start a boot loader.
Here's a page with disassembly of an MBR:
http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm
Why must you write the boot loader?
You could use a ready-made bootloader like GRUB and chainload your PE executable, from it.
Of course, this is very ancient and hairy stuff, but in the good old days, people did this win PE format executables, and a DOS Extender.
For something a little more this-century, why not make your own bootable REACTOS disk, and add your own PE executable written in Delphi to handle the "user shell"?
You could also (but this would require licensing) use the Windows PXE. I think that projects like BartPE probably fall on the gray side of legal, or are at least, unlicensed. Thus, a completely MS-free solution (reactos) for a completely self-contained kiosk PC, with ReactOS, might be more what you are looking for.
Can you write your own operating system? your own UI layer? your own video device drivers? I didn't think so. So use DOS and TurboPascal, or ReactOS and a PE win executable. Or you can use FreePascal and just build your app on a very lightweight portable Linux kernel and root filesystem.