Skip to content
This repository was archived by the owner on Oct 22, 2021. It is now read-only.

Compiling for Mega2560: "TypeError: Cannot read property 'length' of undefined" #374

Closed
arnmulligan opened this issue Oct 22, 2020 · 13 comments
Assignees
Labels
type: imperfection Something isn't working

Comments

@arnmulligan
Copy link

Testing using nightly build arduino-pro-ide_nightly-20201022_Linux_64bit, on Linux 5.8.15-201.fc32.x86_64 with Xfce4.
Arduino AVR Boards 1.8.3

Compiling sketch for Arduino Micro and Uno proceeds as normal.
Compiling sketch for Mega2560 fails before it starts with the following pop-up tooltip:

arduinopro_bug

Doesn't matter whether actual hardware attached or not. Nothing at all output to Problems or Output areas. Nothing apparently related in the trace level logging.

To reproduce: open IDE with a sketch, select Mega2560 board for build, click verify button.

@arnmulligan arnmulligan added the type: imperfection Something isn't working label Oct 22, 2020
@kittaakos
Copy link
Contributor

I tried to just verify against the Arduino Mega or Mega 2560 board with the 1.8.3 avr core, and it worked on macOS. I did not do upload because I do not have such a board. Please help us to narrow down the issue:

  • Do you see errors in the browser log? You can open the Dev Tools with Ctrl/Cmd + Alt + I or from the menu:
    Screen Shot 2020-10-22 at 14 10 34
  • Do you see errors in the server log? Please start the app from a terminal with ./path/to/pro/ide/arduino-pro-ide.

@arnmulligan
Copy link
Author

I don't see any errors appear in the Dev Tools when I press the verify button, but there is a relevant error when I change the board and select the Mega:
boards-data-store.ts:80 Uncaught (in promise) TypeError: Cannot read property 'length' of undefined at BoardsDataStore.<anonymous> (boards-data-store.ts:80) at step (52.bundle.js:63) at Object.next (52.bundle.js:44) at fulfilled (52.bundle.js:35)

As already stated, I don't see anything obvious in the server log (what I meant by "trace level logging").

@kittaakos
Copy link
Contributor

It is hard to say why, but somehow, your local storage got corrupted for the Arduino Mega or Mega 2560 board 😕

Can you please try to remove the invalid entry?

  • Open the Dev Tools,
  • Write localStorage.removeItem('theia:.arduinoProIDE-configOptions-1.8.3-arduino:avr:mega') in the console and press Enter,
  • Close and reopen the IDE,
  • Re-select the Arduino Mega or Mega 2560 board (even if it was selected),
  • Try to verify again.

Thanks!

@arnmulligan
Copy link
Author

That has indeed fixed the issue, thanks.
With regard to why it has got corrupted, all I can say is that this is the first time I have tried the new IDE, so it was a fresh install only a few minutes old. I do also have the classic Arduino IDE installed on the same system but, since the new IDE doesn't bundle the boards, I had to install the Arduino AVR Boards package fresh as well.

So just playing around a little:

  • close the IDE
  • rm -r $HOME/.arduino15/packages/arduino/hardware/avr
  • open IDE, board selection box still shows "Arduino Mega or Mega 2560" from last time
  • select other board or port, search for "mega"
  • option "Arduino Mega" only relevant hit for the 2560
  • select "Arduino Mega"
  • IDE tooltip suggesting installation of "Arduino AVR Boards" core for currently selected "Arduino Mega" board, do I want to install now
  • click yes, core installs
  • board selection box still shows "Arduino Mega"
  • click verify, tooltip appears: "Error: No core is installed for the 'Arduino Mega' board. Please install the core."
  • go to select board, now options "Arduino Mega ADK" and "Arduino Mega or Mega 2560" are available
  • select the latter option
  • click verify
  • original issue is back again

@kittaakos
Copy link
Contributor

So just playing around a little:

  • original issue is back again

Brilliant. Thank you so much for the steps.

I try to do something with this issue, but honestly, I think it's a problem with the core: arduino/arduino-cli#620

This is how it works in the new IDE:

  • You pick a board, we do not know much about it, just its name, (FQBN is missing)
  • You install the core, and we cannot set the FQBN on the currently selected board, because its name has changed.
  • There is no way to fix it unless the user picks the Arduino Mega or Mega 2560 board "again" after the core install.

Or maybe, we should unselect the board, so at least with this behavior, we would force users to pick the board instead of corrupting the boards data store.

Do you have any other suggestions on how to handle this, @ubidefeo, @per1234? Thanks!

@kittaakos
Copy link
Contributor

Do you have any other suggestions on how to handle this

I figured out how to solve this; it requires a bigger change, but it should be doable.

@kittaakos kittaakos self-assigned this Oct 22, 2020
@DeeEmm
Copy link

DeeEmm commented Nov 8, 2020

Not sure if it is related but I get the same error when trying to upload to a Nano. Previously there were no issues and both compile and upload were working fine.

The only thing that I think was changed was in the regular Arduino IDE. I updated boards and libraries (it has been some time since I used the 'old' IDE). After updating I was unable to upload a sketch in the Pro IDE. Maybe this is just a coincidence, IIRC the libraries are shared. I thought I would comment in case it is relevant.

Also. Issuing the localStorage.removeItem('theia:.arduinoProIDE-configOptions-1.8.3-arduino:avr:nano') command in the console and reselecting the board clears the issue for me.

@silvioprog
Copy link

@DeeEmm +1. I got the same problem using 0.1.2-nightly.20201112 / CLI Version: 0.13.0 alpha [17d24eb] on Fedora33 and your suggested steps solved the problem.

@kittaakos
Copy link
Contributor

I figured out how to solve this; it requires a bigger change, but it should be doable.

I am ready with a preview. This is the logically correct way how the IDE should handle board name conflicts. The UX might be strange, though. What do you think, @ubidefeo?

Since the board names can change, the new IDE should handle this gracefully.

Originally posted by @per1234 here:

The differences in names are often intentional. [...] For this reason, mismatches should be expected and handled gracefully by Arduino Pro IDE.

How it works (UX):

  • Prerequisites: No platforms are installed.
  • Select the board Arduino Mega board. The corresponding platform is not installed. The FQBN is unknown.
  • Install the required arduino:avr platform.
  • The selected board is discarded when there is a name mismatch
  • The user has to reselect the board.

How it works (technical):

  • The IDE can recognize that the arduino:avr platform for the currently selected Arduino Mega board (which does not yet have the FQBN) was installed, but there are no exact name matches.
  • Since it is impossible to clearly determine that the arduino:avr:mega FQBN that belongs to the Arduino Mega or Mega 2560 board used to be Arduino Mega before the platform install, the user has to interact with the IDE to resolve this conflict.
  • By clicking on the toat message, the user gets the pre-populated board search with the "old" board name. Altogether, with three clicks, it is possible to resolve the issue in the IDE.

In action:
screencast 2020-12-01 18-14-49__33

For the future:

  • The IDE could do this the other way around and provide an even better UX by automatically selecting the best match from the similar board names. When the board was guessed and picked by the IDE, we should warn the user. Something like this: We picked 'xy' board for you. Do you want to select another one?. This would require fewer, zero, user interactions when there are name conflicts. This approach would work in most cases. Once we decide how the "best match" is calculated from the similar names list, we can improve the UX.

@ubidefeo
Copy link

ubidefeo commented Dec 2, 2020

@kittaakos
I think this is a really good solution for the current state of things.
I guess once we have a revamped board repository and implement the board-centric flow this process might be much better assisted.
@per1234 do you have any feedback to add?

@per1234
Copy link
Contributor

per1234 commented Dec 2, 2020

@ubidefeo I love it. It's the perfect combination of taking advantage of the information provided by the package index, but not imposing the unreasonable expectation for it to match the information in boards.txt.

Great work coming up with this solution @kittaakos!

@ubidefeo ubidefeo reopened this Feb 17, 2021
@ubidefeo
Copy link

@kittaakos

this should not be an issue anymore, right?

@kittaakos
Copy link
Contributor

Correct.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: imperfection Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants