It seems to be more stable in that case. To be fair I had 2 ksoloti patchers and 1 axoloti patcher open. Maxing out on the boards here 
it is also not proven that these crashes were Ksoloti related, it was usually though when I would compile all of them in a row.
EDIT: Just found sth weird, the white noise (noise/uniform) sounds completely different (and kinda terrible) than on an original axoloti. Here are the 2 in comparison.
Are you still getting this with the white noise (uniform)?
Did you try knoise? (The k is anything but silent)
Always great when people report things that don’t work as they should - it looks like I may have introduced a wee inconsistency when I rewrote part of the random number generator part?
Actually the two ways should do the same, but maybe they just don’t.
Haven’t had a listen yet but it might just take the noise back to where it was.
Edit: Waaait… they don’t really do the exact same thing.
The SMMUL instruction multiplies scaled values, doesn’t it. So multiplying, say,
0xFFFFFFFF * 0xFFFFFFFF = 0xFFFFFFFF (1 * 1 = 1)
whereas
0x80000000 * 0x80000000 = 0x40000000 ? (0.5 * 0.5 = 0.25)
whereas randSeed * 196314165 will lead to intentional overflow.
Something very wrong with that noise… I don’t remember it being like this. Axoloti Core & Ksoloti Core
Where’s the bug?
The uniform noise on my gills/h7 sounds fine to me!
Am I using an old object maybe?
Could be the H7 has a faster (T)RNG? I bet it has lots more config bits than the F4 too.
What messed up the STM32F4 noise is declaring and initializing int32_t randSeed = 22222; every time the function was called. This lead to a sort of easily repeating/slowly changing pattern.
After changing it back to static int32_t randseed = 22222; (the static somehow got lost on the way): apparently declaring a variable static inside a function is a special case where it actually only gets initialised once then it would squat inside the function and the value is preserved between calls.
The noise/uniform object hasn’t changed for a decade: it really just calls GenerateRandomNumber() at s-rate, which is more or less deprecated for rand_s32()
I’m still a bit confused
I checked the RNG->DR is fast enough on the H7.
That ___SMMLA is not updating randseed, shouldn’t it read:
static uint32_t randSeed = 22222;
return randSeed = ___SMMLA(randSeed, 196314165, RNG->DR);
Maybe? Sounds about right - those intrinsics are easy to misunderstand for me, as many operate on registers directly without “returning” anything.
I’ve given up on ___SMMLA here due to its “scaled” operation - randSeed SMMLA’d with 196314165 will technically always get smaller (though we’re adding RNG->DR to it so maybe fine)
Just reverted it to plain old
static uint32_t randSeed = 22229; /* Static declaration inside function -> will retain its last value between calls */
return randSeed = (randSeed * 196314163) + RNG->DR;
And the numbers are now prime numbers - chef’s kiss
How fast is fast enough? On the F4 the speed for new random numbers to be ready is (as far as I understand it) (RNG clock = PLL48 = USB clock) / (40 RNG clock cycles) - which means
48 MHz / 40 = 1.2 MHz
I would think this is an acceptable speed as the RNG is mostly ever called at s-rate? Maybe it wasn’t fast enough for true randomness, or a good-sounding one, so they added this pseudo-randomize multiply?
in the F4 using a rand_s32() that only uses RNG->DR:
volatile int32_t vals[32];
for(int i=0 ;i < 32; i++)
vals[i] = rand_s32();
I see repeated values , 7 or 8 times in a row.
On the H7 you don’t get repeats, but… You get a lot of zeros! So something needs looking at there!
The loop is too fast… the RNG value has no time to refresh.
After which clock is the H7 RNG set up to run?
Yep, was just trying to show the speed of the RNG was not fast enough
The H7 is the same 48 clock, not sure what is going on there. Need to look down into chibios to see what is going on. You seem to get 8 random readings, then a load of 0’s. Maybe it does batches of 8 then you have to wait or maybe it is entering an error condition and then clearing…
A lot of trickery going on inside the H7 RNG, a FIFO, clocking via two separate clocks, clock error detection… enjoy
I can’t even find where it is set up in the code, not a good start!
We do have this
#define STM32_RNGSEL STM32_RNGSEL_HSI48_CK
It does seem to generate them in batches of 8, then RNG->DR becomes 0 and you have to wait for the next batch.
HAL Code for the wait:
/* Check if data register contains valid random data */
while (__HAL_RNG_GET_FLAG(hrng, RNG_FLAG_DRDY) == RESET)
{
if ((HAL_GetTick() - tickstart) > RNG_TIMEOUT_VALUE)
{
/* New check to avoid false timeout detection in case of preemption */
if (__HAL_RNG_GET_FLAG(hrng, RNG_FLAG_DRDY) == RESET)
{
hrng->State = HAL_RNG_STATE_READY;
hrng->ErrorCode = HAL_RNG_ERROR_TIMEOUT;
/* Process Unlocked */
__HAL_UNLOCK(hrng);
return HAL_ERROR;
}
}
}
Edit: Actually it seems to generate them in batches of 4, with storage for 8.
Do you need the HAL for that on H7?
No, I will whip out the code to check that flag, or maybe it isn’t necessary really. return randSeed = (randSeed * 196314163) + RNG->DR; is going to give a different value each time RNG->DR is 0, maybe not “random” but will be different, just like it is at the moment with RNG->DR staying the same?
Wow seems, like I really started sth here 
yes this is the white nosie uniform.
I did not try that one. I ended up switching to another noise though, the others seemed fine.
does that mean you have a ksoloti board with a faster processor? 
or is this just the general difference between ksoloti and axoloti?
Seb has found the problem with the random number generator and fixed it, will be in the next release I guess.
I have a prototype of a newer Ksoloti board with a more powerful processor in it, I have been attempting to get all the software running on it…