The Pixelmon config folder, config/pixelmon, is a folder containing numerous .yml file(s) for the various configurable settings Pixelmon supports. It is located in the Minecraft installation's files, which can have different locations depending on the launcher that was used to install the game. This guide to finding your config files covers most of those.

These .yml file(s) can be edited outside of Minecraft with a plain text editor such as Notepad or TextEdit. If edited with a plain text editor, changes will only be reflected when the target world is not online; changing the config file while the world is online will cause no changes to occur to the world until the world is reloaded. On a multiplayer server, editing the config file(s) on the client will only affect client-side settings; server-side settings can only be changed by editing the server .yml files inside the server folder.

The config file(s) and/or folder can be reset to default settings by deleting the file. The file will be regenerated the next time Minecraft is launched. It is recommended to do this when Updating Pixelmon, to ensure any changes made are applied to your file(s).

as stated in the title, we have a nrf52840 dongle (PCA10059) which does not come up normally on a Nvidia xavier devboard. Output of dmesg:

[ 112.940331] usb 1-3.1: New USB device found, idVendor=1915, idProduct=c00a [ 112.940335] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 112.940338] usb 1-3.1: Product: nRF52 Connectivity [ 112.940341] usb 1-3.1: Manufacturer: Nordic Semiconductor [ 112.940343] usb 1-3.1: SerialNumber: EE54BF5A789B [ 112.948394] usb 1-3.1: can't set config

1, error -32

We tried different OS and SW (bootloader/softdevice/application) versions all with the same outcome.

After a lot of testing and tracing we found out, that when we pull out the usb-dongle ot of the usb-socket just that far that the power-pins are still connected and only the connection-pins are disconnected and then plug it back, the device will be detected just fine. Also when using a external usb-hub it will come up normally.

So it seems the problem comes from a timing issue between the xavier-usb (tegra-xusb) driver and the dongle. Probably the dongle delivers the usb-config too slow so that the kernel has no config to select the further loading of cdc_acm.

Is there anything we can do in the bootloader/softdevice/app to somehow fix this problem, so that no external usb-hub is needed?

Parents

• 
  Hi This is not an known issue, but we haven't done any testing on this platform either. I assume you don't have this issue on a regular PC platform? Do you have any means to sniff the USB communication between the dongle and the Nvidia host, so you can see what is going on? Best regards Torbjørn
• 
  Hi This error means that the SoftDevice currently in the dongle is not corresponding to the one provided in the --sd-req parameter, which indicates it is not the S140 v6.1.0 that is on the dongle currently. Is there any chance some other SoftDevice version could be on the dongle? On second thought, a different way to flash the connectivity software is to simply press the button on the dongle to put it in bootloader mode, and use the nRFConnect for Desktop Bluetooth application to program the connectivity firmware. This application will ask you if you want to flash the connected dongle, if you select it from the list of connected devices in the application. Could you try this out and see if it works better? Best regards Torbjørn
• 
  Sorry for the delay but i just now had found time to address this. Downloaded the nrfConnect for Desktop 3.9.0, updated the BLE application to 3.0.0 and flashed it to the dongle. I then also could scan for BT devices so this worked. Unfortunately the error is still the same when plugging into the nvidia Xavier board, where we also updated the kernel to 4.9.253 in the meantime.
• 
  Hi No worries. Any chance you have considered my suggestion of getting an nRF52840DK? I think it will be easier to investigate this with access to logging and a debugger. Best regards Torbjørn
• 
  Will try to get one. Do we need more things then (e.g. special jtag) or only the DK board? I also have a dongle with a pin-header (10 pins) soldered to the bottom of it. But no idea if this helps or how to interface with it. Would this be okay too?
• 
  Hi

  A.St. said:

Do we need more things then (e.g. special jtag) or only the DK board? With the DK you don't need any extras, as it comes with a built in debugger. For this reason it is very useful for development purposes. You can also use the DK to program external boards (such as your dongle), as long as the board supply voltage is similar. A.St. said:

Reply

• 
  Hi

  A.St. said:

Do we need more things then (e.g. special jtag) or only the DK board? With the DK you don't need any extras, as it comes with a built in debugger. For this reason it is very useful for development purposes. You can also use the DK to program external boards (such as your dongle), as long as the board supply voltage is similar. A.St. said:

Children

• 
  We now have a nRF52840dk we will check it out when there is time. Is there some getting started guide? What should we do to debug this problem and how?
• 
  Hi The nRF52840DK user guide is available here. I think the first thing to test could be to run the cdc_acm example on the nRF52840DK with UART logging enabled (available through the virtual comport that the DK sets up), and try to reproduce the issue that you see with your dongle. Please also try the connectivity firmware on the DK, and see if that works or not. Best regards Torbjørn
• 
  For our own custom use-case we were able to fix this problem by first applying power to the board/chips, and then reset the chips after some delay with a GPIO. Nonetheless we finally got some time to start debugging. we've downloaded the latest SDK (17.1.0), put the switches into the expected positions (power source: VDD; sw6: DEFAULT; Power: ON) copied the cdc_acm example (nRF5_SDK_17.1.0_ddde560/examples/peripheral/usbd_cdc_acm/hex/usbd_cdc_acm_pca10056.hex) into the mounted nrf filesystem where the device resets automatically afterwards. Then we connected to /dev/ttyACM0 via minicom with the given terminal settings (115k, 8n1, ...) and also to /dev/ttyACM1 after plugging in the nrfUSB connection. on the ACM0 we get a uard_cli prompt: uart_cli:~$ on the ACM1 we get some data when pressing button 1 and led 3 blinks when typing things in the host-minicom. How can we now see the debug log when plugging in the nrf-usb connection?

Hi

Do you not get log data in the ACM0 terminal?

You should get something like this when running the example (in this case I first connect the USB, then send four characters through the USB CDC comport, and then I remove and reconnect the USB again):

If you want you can also redirect logging to another interface, such as RTT. Then you will not depend on the UART console for logging information, but can use the debug interface instead. To view the RTT log you need to use the J-Link RTT Viewer application, and enable RTT logging by setting NRF_LOG_BACKEND_RTT_ENABLED 1 in sdk_config.h, while setting NRF_CLI_LOG_BACKEND 0.