Config tool command line generation inconsistency

[Fastfox]

Hi,

We have config tool installed to a docker image and we use it in CI(and locally) to generate some definitions for LPC55 compilation. Few weeks back we added some ADC definitions and started to get problems. Details are:

In makefile we say:

.NOTPARALLEL $(GEN_SRCS): $(MEX_FILE)
	rm -rf $(GEN_DIR) && \
	/opt/nxp/MCUX_CFG_v11/bin/tools -noSplash \
      -Load $(MEX_FILE) \
      -HeadlessTool Pins -ExportSrc $(GEN_DIR) \
      -HeadlessTool Clocks -ExportSrc $(GEN_DIR) \
      -HeadlessTool Peripherals -ExportSrc $(GEN_DIR)

and the problem is that sometimes, for example if you add MCU internal temperature measurement ADC config to the mex file, following lines are missing from generated peripherals.h file

/* Command 1 - ADC_TEMP_CMD */
#define ADC0_ADC_TEMP_CMD 1U
/* Trigger 0 - ADC_TEMP_TRIG */
#define ADC0_ADC_TEMP_TRIG 0U

The strange(st) thing here is the sometimes part. In some machines this works(lines are generated) always and in some machines 9/10 fail. And this is with the same docker image so everything should be exactly the same. All the other things are generated correctly. So far we have noticed problems only with ADC definitions.

If you go inside a container that just  failed to generate the lines and run the generation from command line it always succeeds.

Any ideas what is wrong and how the config tools should be used to make it behave consistently?

[_qwerty_]

Update to the problem Fastfox and I are debugging: We noticed the two ADC defines are missing from generated peripherals.h when Config Tool doesn't have network connection. This happens even when we have used GUI to update processor data to local cache through menu -> File -> Data Manager. Still the Config Tool seems to fetch something from internet that changes the C file generation result.

Question 1: Is it a bug in config in config tool that we cannot use it offline?
Question 2: Is there anything we could do to make the offline usage work?
Question 3: Since the command line invocation of Config Tool sometimes works and sometimes doesn't, is there possibly a bug that the file generation doesn't wait for all data that comes from network? It's possible we have some network issues also occasionally that would cause the randomness...

[_qwerty_]

Cache or GUI's view of it seems to have been corrupted. After clearing the cache from "Data Manager" menu and re-downloading the processor data to cache again, the Config Tool is able to generate correct peripherals.h even without network connection.

We would still need to update the cache on CI machine that doesn't have GUI and so far that has been unsuccessful.

[_qwerty_]

Copying "~/.nxp/mcu_data_v11" folder from updated non-dockerized Config Tool to the dockerized Config Tool's corresponding .nxp folder seems to fix the problems on the CI machine.

Would be nice to know is there an easier way but at least this is a workaround.

[liborukropec]

Hello,

two questions:

1. do you remove/delete the container at the end and the data is downloaded again and again?

2. if you still have failing image, can you compare what data is different in compare to the "fresh" from GUI download?

Regards,

Libor

[_qwerty_]

1. Yes
2. Our dockerized Config Tools doesn't have .nxp folder at all in home directory when the docker is started. As a workaround we create that folder and copy-paste up-to-date processor data there.

Would be nice if the Config Tools installer contained all the needed data. And would be nice if there would be more switches when using the tool from command line:
- offline (don't download anything from internet leading to unexpected build results)
- verbose (so we would see what the tool is actually doing when debugging these kind of issues)

Manual could also describe how to import processor data for non-GUI usage (on Linux)

[liborukropec]

Hi,

still I do not know whether the data somehow differs between docker and desktop GUI. Anyway:

Would be nice if the Config Tools installer contained all the needed data

It would mean gigabytes for all processors (almost 500!) and they will become not up-to-date during the time anyway.

offline (don't download anything from internet leading to unexpected build results)

currently there's no direct CLI argument, you can put preferences into the docker image with offline option turned on:

then you can find the preference stored in the $HOME/.nxp/MCUX_Tools/11.0/preferences/.preference.storage4.properties

...
offline=true
...

and this file you can put into your docker container.

Another option is to overwrite the server from which the data is downloaded, but it will pollute the error log with false errors.

See <installdir>/bin/tools.ini and this line:

-Dcom.nxp.restapi.server=https://mcuxpresso.nxp.com

- verbose (so we would see what the tool is actually doing when debugging these kind of issues)

If you want to see more messages in the console, you can tweak the

<installdir>/bin/configuration/logging.properties

and change

java.util.logging.ConsoleHandler.level = SEVERE

 into

java.util.logging.ConsoleHandler.level = WARNING

Manual could also describe how to import processor data for non-GUI usage (on Linux)

Yes, you are right, anyway it is a simple ZIP file that can be extracted into ~/.nxp/mcu_data_v11 folder (here for Linux and tools version 11)

Regards,

Libor

[_qwerty_]

Maybe I'm doing something wrong but setting "offline=true" to ".preference.storage4.properties" file didn't seem to block Config Tools to fetch processor data from internet. I couldn't get the logging improved either by tweaking "java.util.logging.ConsoleHandler.level = WARNING".

Anyway, the root cause for original issue seems to be clear: Config Tools fetches processor data from internet when we load the .mex configuration file and sometimes the processor data is outdated due to network issues. And we have a solution to copy-paste specific content into $HOME/.nxp/mcu_data_v11 folder and then block Config Tools network access with other tools.

I think this is enough for us and discussion could be closed. Thanks for the help!