lichtuberstromt Posted November 22, 2019 Report Share Posted November 22, 2019 I've been slowly working on integrating analog controls into the lovely Goom port for the STM32F4 and hit a bit of a roadblock. The AINSer64 module won't initialize (no pulsing link light). I can get it to work only if I disable the last line of the following function. Commenting it out and returning 0, allows the AINSer64 to do its job, the link led pulses and turning knobs send debug messages with proper pin numbers and values. The Goom synth also works just fine without any of the AINSER code present. Currently the AINSER64 is setup on J19 / SPI 2. s32 SYNTH_Init(u32 mode) { // initialize the AINSER module(s) AINSER_Init(0); // start task xTaskCreate(TASK_Synth_Update, "SynthUpdate", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_SYNTH_UPDATE, NULL); xTaskCreate(TASK_AINSer_Scan, "AINSerScan", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_AINSER_SCAN, NULL); //use J10A.D0 for performance measurements MIOS32_BOARD_J10_PinInit(0, MIOS32_BOARD_PIN_MODE_OUTPUT_PP); // start I2S DMA transfers return MIOS32_I2S_Start((u32 *)&sample_buffer[0], SAMPLE_BUFFER_SIZE, &SYNTH_ReloadSampleBuffer); } I2S is enabled in the config file. I saw that it can conflict with the SRIO SPI, tried setting SRIO_SPI to 0, with no luck. I wasn't sure if that applied here or not. Have tried this same code with ReloadSampleBuffer as an empty function, with the same results. I'm assuming the issue is somewhere in the I2S_Start function, but reading through that I didn't notice any obvious issues. Other AINSer apps like MIDIO128 work fine. I did have issues with the Jitter Monitor though - it just scrolls endlessly, returning empty results for all modules. I haven't delved deeper into that since the module was returning results without any issues outside of trying to implement it in Goom. Any insight into what might be happening here? Thanks Jeff Quote Link to comment Share on other sites More sharing options...
Antichambre Posted November 23, 2019 Report Share Posted November 23, 2019 Humm, why did you create a task for SYNTH_Update(instead of using APP_Tick)? why did you put the AINSER task in synth instead of app.c? Which priority levels do you use? Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted November 23, 2019 Author Report Share Posted November 23, 2019 I put the AINSER Task in Synth.c just to see what part of Synth_Init was causing the issue. Creating a task for SYNTH_Update was a futile attempt at getting things to work, before realizing that I2S_Start seemed to be what was causing the issue. Both tasks are at Priority 3. As long as I don't call MIOS32_I2S_Start, both AINSER and SYNTH_Update tasks work and process / update the control array. Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted November 23, 2019 Author Report Share Posted November 23, 2019 I've moved the AINSER_Scan task back to app.c and SYNTH_Update back to APP_Tick just to make sure I'm not introducing any new issues of my own making, but am still with the same results. Are there any other applications using both the Audio DAC of the STM32F4 and an AINSER module? The only similar synths I could find in tutorials or apps didn't utilize AINSer. Posted the main functions at issue below. SYNTH_Init is where things seem to go wrong. Right now I've got the return MIOS32_I2S_Start commented out - this is the only way I can get AINSer to function and return values. Swapping it with return 0 allows the synth to function, but no AINSER controls work, nor does the pulsing link light on the module ever light. I don't think I have any SPI conflicts, but the SPI_Start sure seems to be the culprit. I'm a little over my head in this project - any thoughts on how to approach debugging this further? Thanks! Jeff #define PRIORITY_TASK_AINSER_SCAN ( tskIDLE_PRIORITY + 3 ) static void TASK_AINSer_Scan(void *pvParameters); void APP_Init(void) { // initialize all LEDs MIOS32_BOARD_LED_Init(0xffffffff); // initialize the AINSER module(s) AINSER_Init(0); // start task xTaskCreate(TASK_AINSer_Scan, "AINSerScan", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_AINSER_SCAN, NULL); // init Synth SYNTH_Init(0); } static void TASK_AINSer_Scan(void *pvParameters) { portTickType xLastExecutionTime; // Initialise the xLastExecutionTime variable on task entry xLastExecutionTime = xTaskGetTickCount(); while( 1 ) { vTaskDelayUntil(&xLastExecutionTime, 1 / portTICK_RATE_MS); // skip delay gap if we had to wait for more than 5 ticks to avoid // unnecessary repeats until xLastExecutionTime reached xTaskGetTickCount() again portTickType xCurrentTickCount = xTaskGetTickCount(); if( xLastExecutionTime < (xCurrentTickCount-5) ) xLastExecutionTime = xCurrentTickCount; // scan pins AINSER_Handler(APP_AINSER_NotifyChange); } } static void APP_AINSER_NotifyChange(u32 module, u32 pin, u32 pin_value) { // toggle Status LED on each AIN value change MIOS32_BOARD_LED_Set(0x0001, ~MIOS32_BOARD_LED_Get()); DEBUG_MSG("APP_AIN_NotifyChange_SER64(%d, %d, %d)\n", module, pin, pin_value); SYNTH_AINSER_NotifyChange (module, pin, pin_value); } s32 SYNTH_Init(u32 mode) { // use J10A.D0 for performance measurements MIOS32_BOARD_J10_PinInit(0, MIOS32_BOARD_PIN_MODE_OUTPUT_PP); // start I2S DMA transfers //return MIOS32_I2S_Start((u32 *)&sample_buffer[0], SAMPLE_BUFFER_SIZE, &SYNTH_ReloadSampleBuffer); return 0; } Quote Link to comment Share on other sites More sharing options...
Antichambre Posted November 23, 2019 Report Share Posted November 23, 2019 It's a Serial Peripheral conflict. J19 and I2S use the same serial peripheral -> SPI3 Switch the AINSER to another SPI port J16 or J8/9 depending on what you already use, SRIO, SD Card etc... Note: you will need a level shifter for J16. Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted November 23, 2019 Author Report Share Posted November 23, 2019 Ah that makes sense - I'm not using any other SPI's - I'll move to J8/9. Thanks for the help! Have been absolutely amazed by this platform and the forum - both are incredibly robust. Usually the answers I need are already in documentation, but when not this forum has consistently provided a whole lot of detailed information. Already thinking about doing another midibox project... Way too many possibilities... Thanks!! Jeff Quote Link to comment Share on other sites More sharing options...
lichtuberstromt Posted November 23, 2019 Author Report Share Posted November 23, 2019 Confirmed, that was all that was wrong! Thank you so much for you help! Quote Link to comment Share on other sites More sharing options...
Antichambre Posted November 24, 2019 Report Share Posted November 24, 2019 Just now, lichtuberstromt said: Confirmed, that was all that was wrong! Thank you so much for you help! You're welcome, have fun with your MB and the future one(s) ;) Best regards Bruno Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.