-
-
Wed 2021.09.29
post #15 'I'd like to back Bangle Js 2 but it says rewards are not guaranteed? For those who back have you received your reward?'
See post #16 by @johan_m_o That's a message from Kickstarter, . . .
After seeing that you have been posting @SirXerox
Bangle.js replacing the screen?
http://forum.espruino.com/profiles/176410/I find it a bit of a stretch to doubt the validity and successes of the Espruino brand here.
Did you follow the link and Actually read the detail there??? (no)
- Shipped over 40,000 official Espruino devices
- Developed 6 further Espruino devices
- Launched and successfully delivered three more KickStarter campaigns
and the forums speak for themselves.
3300 registered users - 5000 forum conversations - nearly 50,000 comments
I participated in the Bangle V1 campaign and also own every Authentic Espruino.
To satisfy your doubts, persuse the forums, review the more than 100 tutorials,
the bazillion apps created by current satisfied consumers
follow the links in
Then if you are still not convinced, . . . wait, . . . and eventually wish you had gotten in early while everyone else is gleefully experimenting and enjoying their progress as you read thoses successes here in the forums.
-
Wed 2021.09.29
I may not be able to resolve your issue @Tx , collecting a bit more detail should assist others.
What process/tutorial was used to update the bootloader? Link please
After resetting using these steps, do we have the same scenario described above?https://www.espruino.com/Bangle.js#resetting-without-loading-any-code
Are you able to step through this process, and if so, at what line is the last possible?https://www.espruino.com/Bangle.js#firmware-updates
Another idea to try:Banglejs not booting
see link 'It's usually pretty much impossible to 'brick' it since the bootloader won't overwrite itself.' -
Mon 2021.09.27
reply to post #34
'I've never seen anyone draw their circuit in the comments before and I love it so much'
@bertjerred feel free to peruse the plethora of posts that @allObjects has done over the years. His expertise in complete embedded ASCII circuit documentation is legendary here within the Espruino forum. I too love it when his skill with a new presentation piques a forgotten hidden corner of the cob web infested aging mind. Always something to garner from that insight.
I also am old school and keeping documentation within the code file ensures that it won't get lost or more so not forgotten during a future code update or modification. When I stumble across some of those special treats, I'll send or post here.
reply to post #35post #28 Thank you :) Keeping it short so you can: 'go try to build build build . . . '
Hope you had an enjoyable time over the week end bit twiddling!! ;-)
-
Mon 2021.09.27
Posted Wed 22nd, five days ago . . .
in news forum Bangle.js 2 now on KickStarter
https://www.kickstarter.com/projects/gfw/banglejs-2-the-open-smart-watch
Goal met. 14 days to go. Consider your pledge to support!
-
So the cable is no longer soldered as in the photo?
Was an attempt to perform the advanced reflashing as it was thought the Pico was bricked?
Was SWD being done?
Solder bridge over BOOT0 on underside of board?
Were the battery contacts on the underside also soldered to?Is the desire to re-flash the device right now?
re: 'i am shure the os is not a problem'
I agree, I just don't know what the commands or sequence are for port communications using Mac and weak using Linux. Others will have to provide that content.
Depending on how high that solder is on the USB tab contacts might raise one of the contacts high enough that it is no longer touching. Any chance solder wick is available to clean up those tab contacts so there is no residual solder?
-
Was attempting to determine which version was flashed.
Not super critical to know just yet, but as the board was just flashed, do you recall which version?
or, when the board does boot
process.env
Attempting to determine if we have a separate flash issue or coding issue in addition to the soldering/use of additional port.
Which pins were soldered? An uploaded image would really assist here.
Is the intent to solder to USART1 or USART2?By chance are Tx and Rx reversed?
Is there a TTL converter such as CP2102?
Regarding OS, I'm not able to push forward further, as my experience is on Windows10 only. Others may be able to, using the detail you have previously provided. -
Sun 2021.09.26
Hi @Samux6146 a few questions.
Q1: Did you have Espruino running previously with code you had written? by chance recall the version?
Q2: Was an attempt made to flash the device? re:boots in bootloader mode
Q3: Has an attempt been made to substitute cables, or re-seat unplug/replug the cable?
Q4: What PC OS? -
Sun 2021.09.26
After re-reading these threads, It appears from the errors that make is more likely the culprit.
This notation might explain why after several make clean cycles,
https://stackoverflow.com/questions/61684562/need-to-run-make-twice-after-make-clean
See green checked item descriptionI looked over NRF5X.make but don't see any commonalities there.
-
Sun 2021.09.26
While looking over the provision.sh file
L140 echo Installing python and pip sudo DEBIAN_FRONTEND=noninteractive apt-get install -qq -y python python-pip
What version of Python need be installed?
I have a user installed version 3.7 that runs from Windows:
Note the version date(s) that didn't seemed to have gotten updated by their release team
C:\WINDOWS\system32>python Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 19:29:22) [MSC v.1916 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>
VSCode somhow loads a version 2.7 that isn't (intentionally) installed on this PC - Maybe inside WSL?
rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ python Python 2.7.12 (default, Aug 22 2019, 16:36:40) [GCC 5.4.0 20160609] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>
Could this version be part of the issue?
Could the dynamic loading of Python during the build have some sort of delay that blocks the scripts from executing timely? -
Sun 2021.09.26
http://www.espruino.com/Reference#l__global_setWatch
'Internally, an interrupt writes the time of the pin's state change into a queue with the exact time that it happened, and the function supplied to setWatch is executed only from the main message loop. However, if the callback is a native function void (bool state) then you can add irq:true to options, which will cause the function to be called from within the IRQ. When doing this, interrupts will happen on both edges and there will be no debouncing.'
-
Sat 2021.09.25 - 07:54pm CST
Have spent 12 hours on this, and it gets even more perplexing:
I have built this on three separate attempts to see if I could uncover a cause and the number of bytes for the same file build changes: (I only ran the provision.sh script once prior)
This shouldn't happen, should it????
While the storage value is consistent: STORAGE: 966656 -> 1007616 the data and code sections change:
FS DATA: 492980 -> 493000 (20 bytes) CODE: 155648 -> 493000 (336136 bytes) FS DATA: 452756 -> 452776 (20 bytes) CODE: 155648 -> 452776 (296248 bytes) FS DATA: 494012 -> 494032 (20 bytes) CODE: 155648 -> 494032 (337168 bytes)
Could this anomaly reveal a cause for the build errors?
Will try flashing tomorrow.Shutting down for the evening to now enjoy both a bourbon and a nice 6yr rye. . . .
-
Wow, and this sequence worked:
make clean make BOARD=NRF52840DK make
src/jsutils.c:374:3: note: called from here NVIC_SystemReset(); ^ /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/toolchain/cmsis/include/core_cm4.h:1790:22: warning: inlining failed in call to 'NVIC_SystemReset': call is unlikely and code size would grow [-Winline] __STATIC_INLINE void NVIC_SystemReset(void) ^ src/jsutils.c:374:3: note: called from here NVIC_SystemReset(); ^ python scripts/check_elf_size.py NRF52840DK espruino_2v08.220_nrf52840.elf Testing espruino_2v08.220_nrf52840.elf for NRF52840DK STORAGE: 966656 -> 1007616 FS DATA: 492980 -> 493000 (20 bytes) CODE: 155648 -> 493000 (336136 bytes) Code area Fits before Storage Area arm-none-eabi-objcopy -O ihex espruino_2v08.220_nrf52840.elf espruino_2v08.220_nrf52840.hex Merging SoftDevice python scripts/hexmerge.py /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/s140/hex/s140_nrf52_6.0.0_softdevice.hex espruino_2v08.220_nrf52840.app_hex -o espruino_2v08.220_nrf52840.hex rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$
Fianlly, espruino_2v08.220_nrf52840.elf and espruino_2v08.220_nrf52840.hex get built!
I have no explanation other than I removed the RELEASE=1 part and cleaned in separate steps:
make clean make BOARD=NRF52840DK make
vs
make clean && BOARD=NRF52840DK RELEASE=1 make
-
Sat 2021.09.25
Now this is interesting.
I closed the VSCode workspace and shut down VSCode. Relaunched.
Ran make clean followed by make clean && BOARD=NRF52840DK RELEASE=1 make
and now get a unique new error:
make: *** [libs/compression/heatshrink/heatshrink_encoder.o] Error 127
rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ make clean Cleaning targets rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ make clean && BOARD=NRF52840DK RELEASE=1 make Cleaning targets Generating platform configs Generating pin info Generating JS wrappers WRAPPERSOURCES = src/jswrap_array.c src/jswrap_arraybuffer.c src/jswrap_dataview.c src/jswrap_date.c src/jswrap_error.c src/jswrap_espruino.c src/jswrap_flash.c src/jswrap_functions.c src/jswrap_interactive.c src/jswrap_io.c src/jswrap_json.c src/jswrap_modules.c src/jswrap_pin.c src/jswrap_number.c src/jswrap_object.c src/jswrap_onewire.c src/jswrap_pipe.c src/jswrap_process.c src/jswrap_promise.c src/jswrap_regexp.c src/jswrap_serial.c src/jswrap_storage.c src/jswrap_spi_i2c.c src/jswrap_stream.c src/jswrap_string.c src/jswrap_waveform.c libs/compression/jswrap_heatshrink.c libs/math/jswrap_math.c libs/graphics/jswrap_graphics.c libs/network/jswrap_net.c libs/network/http/jswrap_http.c libs/network/js/jswrap_jsnetwork.c libs/bluetooth/jswrap_bluetooth.c libs/neopixel/jswrap_neopixel.c DEFINES = -DGIT_COMMIT=8c51e53 -DNO_ASSERT -DRELEASE -DBUILDNUMBER="220" -DNRF52840DK -DCONFIG_GPIO_AS_PINRESET -DBOARD_PCA10056 -DNRF_USB=1 -DUSB -DNEOPIXEL_SCK_PIN=22 -DNEOPIXEL_LRCK_PIN=23 -DUSE_DEBUGGER -DUSE_TAB_COMPLETE -DUSE_HEATSHRINK -DUSE_MATH -DUSE_GRAPHICS -DUSE_NET -DUSE_NETWORK_JS -DBLUETOOTH -DUSE_NEOPIXEL -DS140 -DNRF_SD_BLE_API_VERSION=6 -D__HEAP_SIZE=0 -DBLE_STACK_SUPPORT_REQD -DSWI_DISABLE0 -DSOFTDEVICE_PRESENT -DFLOAT_ABI_HARD -DNRF52_SERIES -DNRF52840_XXAA -DNRF52840 -DNRF5X -DNRF5X_SDK_15 -DUSE_APP_CONFIG -DARM -DLINK_TIME_OPTIMISATION -DEMBEDDED CC libs/compression/heatshrink/heatshrink_encoder.o make: arm-none-eabi-gcc: Command not found Makefile:797: recipe for target 'libs/compression/heatshrink/heatshrink_encoder.o' failed make: *** [libs/compression/heatshrink/heatshrink_encoder.o] Error 127 make: *** Waiting for unfinished jobs.... make: *** wait: No child processes. Stop. rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$
-
With modified make instructions from:
https://github.com/espruino/Espruino/blob/master/README_Building.md
EDIT: I didn't catch that the build instruction beneath the nRF52 heading was for the 832
Left here in case it provides a cluetargets/nrf5x/jshardware.c:1016:3: note: called from here nrf_delay_us((uint32_t)microsec); ^ python scripts/check_elf_size.py NRF52832DK espruino_2v08.220_nrf52832.elf Testing espruino_2v08.220_nrf52832.elf for NRF52832DK STORAGE: 442368 -> 483328 FS DATA: 411912 -> 411928 (16 bytes) CODE: 126976 -> 411928 (284468 bytes) Code area Fits before Storage Area arm-none-eabi-objcopy -O ihex espruino_2v08.220_nrf52832.elf espruino_2v08.220_nrf52832.hex Merging SoftDevice python scripts/hexmerge.py /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_12/components/softdevice/s132/hex/s132_nrf52_3.1.0_softdevice.hex espruino_2v08.220_nrf52832.app_hex -o espruino_2v08.220_nrf52832.hex rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$ ls app espruino_2v08.220_esp32.bin NRF_Bootloader.md benchmark espruino_2v08.220_esp32.elf README_Building.md boards espruino_2v08.220_esp32.tgz README_BuildProcess.md build espruino_2v08.220_nrf52832.app_hex README.md ChangeLog espruino_2v08.220_nrf52832.elf scripts CONTRIBUTING.md espruino_2v08.220_nrf52832.hex src CURRENT_BOARD.make espruino_esp32.bin targetlibs dist_licences.txt gcc-arm-none-eabi-8-2018-q4-major targets dist_readme.txt gen tests Dockerfile libs Vagrantfile Doxyfile LICENSE workspace.code-workspace doxygen make xtensa-esp32-elf esp-idf Makefile espruino misc rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$
Now I see the .elf and .hex files.But how do I move the generated .hex file to the local Windows10 file system in order to flash with esptool?
EDIT: 06:56pm CST
Windows stores in two locations:The 832 .hex file was created at:
C:\Users\robin\Espruino\espruino_2v08.220_nrf52832.hex
and VSCode uses:
C:\Users\robin\AppData\Local\Temp
So, when the 840 .hex file is generated, I expect it will be accessible using the FileManger from the above location.I was under the impression that output was stored in <user>/AppData/local but nothing there.
EDIT: 04:48pm CSTOops! That .hex is not the resultant output, but an intermediate 832 version. I'm seeking the 840 version which doesn't seem to get built
-
Sat 2021.09.25
My original continuation is actually a unique new error specific to the DK nRF52840DK
Progress made after successful install of SDK15, but a new error surfaced:
make: *** [espruino_2v08.220_nrf52840.elf] Error 1
CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic/nrf_atomic.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic_flags/nrf_atflags.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/ble_link_ctx_manager/ble_link_ctx_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_error_handler_gcc.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/pm_mutex.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_advdata.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_conn_params.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_srv_common.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_conn_state.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/ble_services/ble_nus/ble_nus.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_id.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_database.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_data_storage.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/id_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/security_manager.o targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.c: In function 'pm_buffer_block_acquire': targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.c:104:46: warning: comparison of integer expressions of different signedness: 'int' and 'uint32_t' {aka 'long unsigned int'} [-Wsign-compare] if ((i - first_locked_mutex + 1) == n_blocks) ^~ CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/security_dispatcher.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/gatt_cache_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/gatts_cache_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/timer/app_timer.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fds/fds.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/queue/nrf_queue.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_util_platform.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/sdk_mapped_flags.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_error.o targetlibs/nrf5x_15/components/libraries/fds/fds.c: In function 'write_execute': targetlibs/nrf5x_15/components/libraries/fds/fds.c:1237:16: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!record_find_by_desc(&desc, &page)) ^ targetlibs/nrf5x_15/components/libraries/fds/fds.c:1245:9: note: here case FDS_OP_WRITE_HEADER_BEGIN: ^~~~ CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/nrf_assert.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh_ble.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh_soc.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/experimental_section_vars/nrf_section_iter.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fstorage/nrf_fstorage.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fstorage/nrf_fstorage_sd.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic_fifo/nrf_atfifo.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/strerror/nrf_strerror.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/balloc/nrf_balloc.o LD espruino_2v08.220_nrf52840.elf src/jslex.o: file not recognized: file format not recognized collect2: error: ld returned 1 exit status make/targets/ARM.make:2: recipe for target 'espruino_2v08.220_nrf52840.elf' failed make: *** [espruino_2v08.220_nrf52840.elf] Error 1 rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$
-
Sat 2021.09.25
While builds for the PICO and WIFI are problematic, and Make is running, I made an attampt at the nRF52840DK to see if progress could be made outside the original board list.
Made progress there after successful install of SDK15, but a new error surfaced:
make: *** [espruino_2v08.220_nrf52840.elf] Error 1
CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic/nrf_atomic.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic_flags/nrf_atflags.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/ble_link_ctx_manager/ble_link_ctx_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_error_handler_gcc.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/pm_mutex.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_advdata.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_conn_params.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_srv_common.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/common/ble_conn_state.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/ble_services/ble_nus/ble_nus.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_id.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_database.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/peer_data_storage.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/id_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/security_manager.o targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.c: In function 'pm_buffer_block_acquire': targetlibs/nrf5x_15/components/ble/peer_manager/pm_buffer.c:104:46: warning: comparison of integer expressions of different signedness: 'int' and 'uint32_t' {aka 'long unsigned int'} [-Wsign-compare] if ((i - first_locked_mutex + 1) == n_blocks) ^~ CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/security_dispatcher.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/gatt_cache_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/ble/peer_manager/gatts_cache_manager.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/timer/app_timer.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fds/fds.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/queue/nrf_queue.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_util_platform.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/sdk_mapped_flags.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/app_error.o targetlibs/nrf5x_15/components/libraries/fds/fds.c: In function 'write_execute': targetlibs/nrf5x_15/components/libraries/fds/fds.c:1237:16: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!record_find_by_desc(&desc, &page)) ^ targetlibs/nrf5x_15/components/libraries/fds/fds.c:1245:9: note: here case FDS_OP_WRITE_HEADER_BEGIN: ^~~~ CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/util/nrf_assert.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh_ble.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/softdevice/common/nrf_sdh_soc.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/experimental_section_vars/nrf_section_iter.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fstorage/nrf_fstorage.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/fstorage/nrf_fstorage_sd.oCC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/atomic_fifo/nrf_atfifo.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/strerror/nrf_strerror.o CC /mnt/c/Users/robin/Espruino/targetlibs/nrf5x_15/components/libraries/balloc/nrf_balloc.o LD espruino_2v08.220_nrf52840.elf src/jslex.o: file not recognized: file format not recognized collect2: error: ld returned 1 exit status make/targets/ARM.make:2: recipe for target 'espruino_2v08.220_nrf52840.elf' failed make: *** [espruino_2v08.220_nrf52840.elf] Error 1 rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$
-
-
Sat 2021.09.25 - 12:53pm CST
Similar errors occur for WIFI also:
make clean && make source scripts/provision.sh ESPRUINOWIFI BOARD=ESPRUINOWIFI make
CC libs/tv/tv.o CC targets/stm32/jshardware.o CC targets/stm32/stm32_it.o libs/tv/tv.c:80:30: error: unknown type name 'TIM_TypeDef' unsigned int jshGetTimerFreq(TIM_TypeDef *TIMx); ^~~~~~~~~~~ libs/tv/tv.c: In function 'TIM4_IRQHandler': libs/tv/tv.c:91:3: error: implicit declaration of function 'TIM_ClearITPendingBit' [-Werror=implicit-function-declaration] TIM_ClearITPendingBit(TVTIMER, TIM_IT_Update); ^~~~~~~~~~~~~~~~~~~~~ libs/tv/tv.c:64:31: error: 'TIM4' undeclared (first use in this function) [#define](http://forum.espruino.com/search/?q=%23define) TVTIMER TIM4 ^~~~ libs/tv/tv.c:91:25: note: in expansion of macro 'TVTIMER' TIM_ClearITPendingBit(TVTIMER, TIM_IT_Update); ^~~~~~~ cc1: some warnings being treated as errors Makefile:797: recipe for target 'targets/stm32/jshardware.o' failed make: *** [targets/stm32/jshardware.o] Error 1 rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$
-
Sat 2021.09.25 - 12:41pm CST
Finally progress! Make is trying to do something.
Thank you @fanoush as I now see the .o files being built within the terminal window.
Even with a preceeding:make clean && make
not out of the woods yet,
and knowing I just recently cloned Espruino, still won't build without error;
libs/filesystem/fat_sd/spi_diskio.c:556:23: warning: conversion to 'DWORD' {aka 'long unsigned int'} from 'int' may change the sign of the result [-Wsign-conversion] *(DWORD*)buff = ((WORD)((csd[10] & 124) >> 2) + 1) * (((csd[11] & 3) << 3) + ((csd[11] & 224) >> 5) + 1); ^ CC targets/stm32/jshardware.o libs/tv/tv.c:80:30: error: unknown type name 'TIM_TypeDef' unsigned int jshGetTimerFreq(TIM_TypeDef *TIMx); ^~~~~~~~~~~ libs/tv/tv.c: In function 'TIM4_IRQHandler': libs/tv/tv.c:91:3: error: implicit declaration of function 'TIM_ClearITPendingBit' [-Werror=implicit-function-declaration] TIM_ClearITPendingBit(TVTIMER, TIM_IT_Update); ^~~~~~~~~~~~~~~~~~~~~ libs/tv/tv.c:64:31: error: 'TIM4' undeclared (first use in this function) [#define](http://forum.espruino.com/search/?q=%23define) TVTIMER TIM4 ^~~~ libs/tv/tv.c:108:27: error: 'SPI_I2S_IT_RXNE' undeclared (first use in this function) SPI_I2S_ITConfig(TVSPI, SPI_I2S_IT_RXNE, DISABLE); ^~~~~~~~~~~~~~~ libs/tv/tv.c:108:44: error: 'DISABLE' undeclared (first use in this function) SPI_I2S_ITConfig(TVSPI, SPI_I2S_IT_RXNE, DISABLE); ^~~~~~~ libs/tv/tv.c:111:3: error: implicit declaration of function 'RCC_AHB1PeriphClockCmd'; did you mean 'RCC_AHB1Periph_TVDMA'? [-Werror=implicit-function-declaration] RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_TVDMA, ENABLE); ^~~~~~~~~~~~~~~~~~~~~~ RCC_AHB1Periph_TVDMA libs/tv/tv.c:62:32: error: 'RCC_AHB1Periph_DMA2' undeclared (first use in this function); did you mean 'RCC_AHB1Periph_TVDMA'? [#define](http://forum.espruino.com/search/?q=%23define) RCC_AHB1Periph_TVDMA RCC_AHB1Periph_DMA2 ^~~~~~~~~~~~~~~~~~~ libs/tv/tv.c:111:26: note: in expansion of macro 'RCC_AHB1Periph_TVDMA' RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_TVDMA, ENABLE); ^~~~~~~~~~~~~~~~~~~~ libs/tv/tv.c:111:48: error: 'ENABLE' undeclared (first use in this function) RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_TVDMA, ENABLE); ^~~~~~ libs/tv/tv.c:117:3: error: unknown type name 'DMA_InitTypeDef' DMA_InitTypeDef DMA_InitStructure; ^~~~~~~~~~~~~~~ libs/tv/tv.c:118:3: error: implicit declaration of function 'DMA_StructInit'; did you mean 'graphicsStructInit'? [-Werror=implicit-function-declaration] DMA_StructInit(&DMA_InitStructure); ^~~~~~~~~~~~~~ graphicsStructInit libs/tv/tv.c:119:20: error: request for member 'DMA_PeripheralBaseAddr' in something not a structure or union DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)(&(TVSPI->DR)); ^ libs/tv/tv.c:120:20: error: request for member 'DMA_PeripheralDataSize' in something not a structure or union DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte; // DMA_PeripheralDataSize_HalfWord and 16 bit? ^ libs/tv/tv.c:120:46: error: 'DMA_PeripheralDataSize_Byte' undeclared (first use in this function) DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte; // DMA_PeripheralDataSize_HalfWord and 16 bit? ^~~~~~~~~~~~~~~~~~~~~~~~~~~ libs/tv/tv.c:121:20: error: request for member 'DMA_PeripheralInc' in something not a structure or union DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; ^ CC targets/stm32/stm32_it.o libs/tv/tv.c:121:41: error: 'DMA_PeripheralInc_Disable' undeclared (first use in this function) DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; ^~~~~~~~~~~~~~~~~~~~~~~~~ libs/tv/tv.c:122:20: error: request for member 'DMA_MemoryDataSize' in something not a structure or union DMA_InitStructure.DMA_MemoryDataSize = DMA_PeripheralDataSize_Byte; ^ libs/tv/tv.c:123:20: error: request for member 'DMA_MemoryInc' in something not a structure or union DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable; ^ libs/tv/tv.c:123:37: error: 'DMA_MemoryInc_Enable' undeclared (first use in this function) DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable;
Is there any way to get the make output to stop generating output once an error is detected?The terminal window scrolls the earliest off the top.
Ctrl+C hit-n-miss
-
Sat 2021.09.25 - 12:24pm CST
Back online after two separate reboots. The PATH Env var is now half it's expected corrupt size, and using the clarification text now allows the installation of gcc which both @MaBe and @fanoush expected was the culprit.
Not 100% sure the actual configuration fix, but likely the fact two versions of Python were present, the unexpected 2nd as a result of updating nRFConnect as from my original hunch.
This is new:
Provision FAMILY = STM32F4 ===== ARM installing gcc-arm-embedded rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/Espruino$
A new version GCC being installed -
Sat 2021.09.25
How about directly to the 'Tutorials' forum heading:
Home >> Tutorials
http://forum.espruino.com/microcosms/130/ -
Sat 2021.09.25 - 11:49am CST
'there is no boards/PICO.py file'
Somewhere in the documentation I took the literal text 'PICO' as the only valid board name in the list of available boards. 'PICO_R1_3.py' is a filename. Subtle difference, but I'm following the documentation verbatim. Just can't find that location on github right now, but will post when I stumble across it.
So, no this error doesn't explain what may be intuitive to you.
'Isn't arm-none-eabi-gcc: Command not found message in plain English?'
I guess it comes with experience:'Experience is what you get when you dont get what you wanted!'
Thr 2021.09.30
Well that was short lived.
After several days of trial and error, I thought I had a work around using two separate 'make clean' steps.
While that seemed to work, it is only around three out of five attempts. I have even tried switching the provision.sh targets, cleaning, build, then switching back to the desired target with limited success.
Q: Is it necessary to run the provision.sh script each and every time a build is desired? (?no?)
I've even verified after each clean step the the src and gen folders are gone of .o compiled files before I start the build.
I'm wondering if there is some kind of file locking hiccup within Windows10 that blocks the ability of the make utility from writing the file timely, as the errors are never consistent. I'd like to isolate/eliminate whether it might be the file system.
Q: Does anyone know of a trick to add a small delay between each .o file compile with make or gcc to slow down the build?