Home/Support/Support Forum/9P9215 NETOS Bootloader modification advice
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

9P9215 NETOS Bootloader modification advice

0 votes
We are pretty much using the stock 7.5.2 bootloader with a small modification to "customizeSetupCS0(void);" for our fpga mapping.

I want to move the recovery bootloader (TFTP) force input switch from GPIO4 to GPIO69 by altering "customizeIsImageDownloadForced()" in "customizeBootloader.c". I am successful in moving it to some lower GPIO #'s such as GPIO1, but for some reason I can't get it to work at GPIO69. This GPIO69 access code works fine when used in the app image, but not in the bootloader. I even tried using narm_read_reg primitives to configure and read this gpio directly and it still wont work. Is there anything that can override gpio pins from configuration & reading that I can check?
asked Jan 29, 2016 in Embedded Devices by marzahld New to the Community (7 points)

Please log in or register to answer this question.

2 Answers

0 votes
This should work. There is nothing special connected to GPIO[69]
Try using simple_serial driver annd bsp_printf() function to print register values. Set the GPIO register values explicitly, then read them back. Compare to working values in your application. It should be set as input by default:
answered Mar 3, 2016 by LeonidM Veteran of the Digi Community (4,454 points)
0 votes
I fixed it! The problem was that even though I had it set as an INPUT in gpio.h as stated by Leonid, it is *not enough* to do this:


Additionally, you must also change the Digi IOP MUX defaults from USE_2ND_PATH, to INTERNAL USE. I'm unsure of what consequences could come from changing these Digi defaults for the 9p9215. So far I have not found any. They may have been set this way for something that was part of the 9p9215's eval board? I think I am going to set all of mine to internal only in the event this could be causing some other issues.


Alternatively you *can* reconfigure the pin in your own code. The reason it didn't work for me the first time, is that a neighboring pin which should have also been INPUT was also suffering from the same IOP MUX issue causing my pin 69 input to be pulled in the wrong direction.

Hope this helps someone else.
answered Mar 30, 2016 by marzahld New to the Community (7 points)