I have a very strange behavoir here. Tried to find the reason for 2 days and am only confused now…
When I connect the battery to the board, it makes the start sound.
Serial monitor shows the normal messages about battery level regularly.
If I call TurnSaberBaseOn in the Setup or Loop of my Prop-implementation, this also works: The blade retraction sound plays and after this the continous blade sound this turning it of.
If I send serial output in my prop loop, it is shown in the serial monitor.
So, software loop seems fine.
But: All hardware output seems to be disabled:
The green LED on board if off and if I send something to e.g. port Free2 and have a look with the oscilloscope, nothing happens.
Exactly 2:40 minutes after start, the green LED starts working and the Free2 port also shows the expected PWM output signal. This drives me crazy. The waiting time is always between 2:30 minutes and 2:45 minutes.
No difference if turnSaberBaseOn is called true or not.
I also tried:
formating SD card
try a second proffie board. Same behavoir, so I think it is a software problem?
using a very simple prop sketch to reproduce the pwm behavoir above:
void Setup() override
{
PropBase::Setup();
delay(1000);
pinMode(blade6Pin, OUTPUT);
delay(10); // Short delay to ensure pin is ready
LSanalogWriteSetup(blade6Pin);
}
void Loop() override
{
PropBase::Loop();
uint32_t value = millis() % 2000 < 1000 ? 255 : 0;
Serial.println("Setting blade6Pin to " + String(value) + "%");
analogWrite(blade6Pin, value);
}
The serial output appears immediately after start-up. The PWM on blade6Pin only becomes active after approximately 160 seconds.
Does anyone have any idea where else I could look?
This is a weird one, but I may have a theory.
My guess is that for some reason, the GPIO block isn’t receiving a clock signal.
There is a bit for turning the GPIO clock signal on/off, and when it’s off, almost all GPIO functions re frozen.
Now, some of the things you’re doing is a bit weird though.
If you’re using LSanalogWriteSetup(), then you should use LSAnalogWrite() to set the PWM duty, not analogWrite(). anlogWrite() does it’s own setup which may interfere, so let’s try changing that first.
Basically, the problem is that the PWM loop counter uses == instead of >= to decide when to set the counter back to zero. The timer is 32-bit, and if the pre-scaler is set to 3, it would take 161 seconds for it to wrap around. \frac{2^{32}}{80Mhz / 3} = 161.06 seconds
I think you can avoid this by using LSAnalogWrite instead of analogWrite().
Wow, such a quick and expert reply! I think this is the best-supported project I know.
Thanks for the background information and tips. That seems to fit – if I use either LS or direct access, keeping them strictly separate, the problem disappears. It’s interesting to hear the explanation for why it’s exactly 160 seconds.
However, I’ve now made another observation when comparing “LS” and “direct”:
When controlling the port directly (i.e. without using LS to set Init and Value), I see a clean line on the oscilloscope at the maximum value 32768:
If I use the LS system with the same code and value, the signal appears significantly more erratic:
I need PWM because I want to control a motor with directional switching via an H-bridge.
Ah, that explains the oscilloscope signal, of course: So in the second image, it’s only 50% PWM instead of 100%.
That was my mistake then:
I automatically assumed that the rules would be retained when programming a sibling function.
But I hadn’t found any documentation on the LS variant in a hurry.
Thank you very much!
PS: I’m curious – what does the abbreviation LS stand for?
