Been tinkering with the GPIO lines of the SBL. Turned the "High Current Drive" option ON and am running LED's via some resistors for testing.
After setting 3 - 4 and 12 - 15 OFF (with the Web interface, a Pxx=0, or using a Machine Command), then making that the default with Machine Command MP, line 13 (UART1 TX) insists on coming ON about two sec after power-up for perhaps a second, then turning off. The rest of the pins stay off during power-up.
Conversely, when setting those same lines to be all ON, and making that the power-on default, line 13 comes ON about a second ahead of all the rest.
I would really like everything to stay off during power up. It'll make things much easier. I can avoid using pin 13 I guess, but I wonder if I am missing something or if it's a known issue.
Thanks.
SBL 2e - glitch?
Re: SBL 2e - glitch?
This is the boot monitor setting the pin as serial port.
My guess is the code initializes both ports and then chooses which one to use depending on the
setting of the boot port. This should probably be changed.
I'm in the middle of doing some SBL2E work I'll see if I can fix this in the next week or so.
My guess is the code initializes both ports and then chooses which one to use depending on the
setting of the boot port. This should probably be changed.
I'm in the middle of doing some SBL2E work I'll see if I can fix this in the next week or so.
Re: SBL 2e - glitch?
Thanks for the prompt response.
One of the uses we're interested in using the SBL for is to remotely power-cycle a locked-up WISP radio in a cluster configuration such that we don't have to roll a truck. If even one of the radios still has connectivity, we can TELNET in and toggle one of the SBL's pins to kill / restore power to that unit.
This is why it'd be good for all the GPIO lines to come up identically for us.
One of the uses we're interested in using the SBL for is to remotely power-cycle a locked-up WISP radio in a cluster configuration such that we don't have to roll a truck. If even one of the radios still has connectivity, we can TELNET in and toggle one of the SBL's pins to kill / restore power to that unit.
This is why it'd be good for all the GPIO lines to come up identically for us.
-
- Posts: 513
- Joined: Sat Apr 26, 2008 7:14 am
Re: SBL 2e - glitch?
With the exception of the STDIO comm port, the default should probably be the reset condition of the processor which is probably to define most pins as Hi-z inputs. Maybe the monitor could have an option to configure a mask for the DDR registor and any output levels to over-ride the reset state if needed?
Re: SBL 2e - glitch?
Just upgraded to the 1.58 FW and this problem still persists...
Any plans to fix?
Thx.
Any plans to fix?
Thx.
Re: SBL 2e - glitch?
This is the monitor setting the port up as a serial port.
The application code has no effect on this start up glitch.
Anyway to use a different pin?
If you can't use a different pin then can you open a support ticket and I'll look at modifying the monitor to leave things as inputs.
In general a support ticket is a more reliable way to get things done as the support system nags me
about things that are still unresolved,
My attention to the general news group will vary a lot, if I'm really busy I could go two weeks without reading it,
other times when I'm stuck or avoiding something I'll read it three times a day...
Paul
The application code has no effect on this start up glitch.
Anyway to use a different pin?
If you can't use a different pin then can you open a support ticket and I'll look at modifying the monitor to leave things as inputs.
In general a support ticket is a more reliable way to get things done as the support system nags me
about things that are still unresolved,
My attention to the general news group will vary a lot, if I'm really busy I could go two weeks without reading it,
other times when I'm stuck or avoiding something I'll read it three times a day...
Paul