I have an STM32F4 Discovery, which is almost exactly like the STM32F407 Discovery (aka, DISC1).
I loaded the Audio Weaver firmware.
I followed the directions in your PDF to a "T".
I had the audio system plugged into the board.
I set the volume on the PC to 75% (Another user wrote that at 100%, there was no sound).
I opened Bach with with Windows Media Player and I heard sound.
YIPEE!, I said, and five seconds later the firmware died.
So, I reset the board, chnaged the mode back to USB in the Server app, refreshed Audio Weaver Designer and tried again, and again, and again, and shortly after the board starts to process some audio, five seconds or so, the firmware hangs.
I could really do with some, thoughts, guidance here.
3:43pm
Is there any one that would care to comment? Would anyone care to suggest an approach to troubleshooting this firmware crashing problem?
3:57pm
Are you running the binary found in the Bin folder or did you create the binary by compiling one of the projects (Keil, IAR, or SW4STM32)?
This firmware has been carefully tested on an STM32F407 MB997 C-01 Discovery board. What is the exact board and board rev number you are running on?
10:29pm
So there is no ambiguity in my answer, the exact file I flashed in my STM32F4 Discovery board is,
C:\DSP Concepts\AWE BSP stm32f407 v1.2\Bin\STM32F407_Discovery.bin.
My module is, MB997 B-00.
The only difference that STMicroelectronics talks about between the two variation is that my board has an ST-Link/V2 interface and the MB997 C-01 has a ST-Link/V2-A interface. Both interfaces do SWD, the second also does VCP and Mass Storage. The accelerometer's are different chips, STM calls the newer one a STM32F407G-DISC1 and both have the same MCU, a STM32F407VGT6. The newer board is also declared to be mbed enabled, which likely is a result of the firmware in the USB interface chip, the STM32F103CBT6 versus the STM32F103C8T6, the CBT6 having more flash storage.
4:16pm
Rebuilding and downloading under Keil with this model produces clean audio with no crashes:
10:38pm
I did not rebuild the code, I do not have Keil. I have Atollic TrueStudio and System Workbench, all up to date.
When I create a new project in Audio Weaver Designer, my Layout shows 4 channels. That made sense to me as the PDF for the DSP Engine (binary) says, and I quote,
I see 3 channels when the Server is in Native mode.
4:20pm
Notice that our STM32F407 Discovery board has only 3 inputs (see AWD model above). The AudioWeaver model you show has 4 inputs. Are you perhaps attempting to run STM32F407 specific firmware on a board other than an ST STM32F407 Discovery board?
10:44pm
STM calls my board a STM32F4DISCOVERY and yours a STM32F407G-DISC1, DocID022256 Rev 6 , Page 7/34, the file name being, DM00039084.pdf.
Again, both boards have identical MCUs, and STM32Cube seems to treat them the same as well.
4:40pm
(Note: it's ok for the HW and Layout to have different channel counts. It's just that the layout's 4th channel will be zero-filled by the firmware when the HW only has 3 channels.)
10:47pm
I did a lot of starts and find that the amount of time before the DSP engine hangs varies somewhat, 5 seconds and once it ran for almost 30 seconds.
While it is running, all channels are actually displaying activity on the Float Meter Sinks. The mic channels are coincident with each other, the sound chain of bach has different and varying levels from each other as they are really stereo.
11:03pm
I did try to build a new binary.
I placed the content of the ZIP into my System Workbench default work folder and opened the project. I selected Build All and it did so, completing without any errors.
I flashed the resulting binary into the board and when I tried to change to USB mode on the Server, I got,
This is the log from the ST-Link Utility,
Flashing th DSP Concepts binary, the ST-Link Utility log is,
And the Server log says,
So, as you can see, I'm at a loss as to what is wrong with both problems,
9:03am
Please try this newer version: https://app.box.com/s/oe3ko9i4p95kifme4i1cqqumv310tsvl
12:30pm
I downloaded the RAR file and tested each of the three DSP engines (binary files) in the distribution.
Late last night, I was trying to figure out why the System Workbench (SW4STM32) binary kept telling me "It was not ST". I was unable to do so. What I did notice was that ENABLE_MIC is defined in the project files for EWARM and MDK_ARM, but does not show up at all in the SW4STM32 project files. Hm.....
I homed in on this to look at, only because in a previous entry here, you spoke of my Layout having Four Inputs when your Layout had Three Inputs. I recall quoting you a passage from your documentation stating that the Microphone input is split from Monaural to Stereo, thus Four inputs.
So, poking around in the code, that's what I saw.
I did try defining the Symbol ENABLE_MIC, leaving it undefined or defining it in the code and compiling it with SW4STM32 and had no luck at all.
Turns out, I would have to purchase the commercial license for Atollic to be able to import the EWARM code stream into it to see how that worked and thus that avenue of investigation is not open to me.
So, there you have it, the two binaries created by the commercial products work as designed and the one from the FOSS is non-functional.
11:02am
We found a bug in the v1.2 release. We've corrected it and will be posting updated v1.3 versions shortly. Sorry for the inconvenience!
12:32pm
Ah, I think there could be another bug lurking in there with the System Workbench (SW4STM32) code pool.
12:56pm
Would you try the SW4STM32 binary from this link:
https://app.box.com/s/9f9aflyafmcj1br04hmuusgqel410vqc
3:58pm
It's Thanksgiving here in Canada.
I finally got around to testing the binaries in the above file. What an odyssey?
I sometimes use Microsoft Edge. On Friday, an interesting new article on the Microsoft Edge MSN start Page caught my eye and I clicked on it to read it. Immmediately it post a message that I have an infection on my PC and starts verbalizing this over the sound as well. I turned off the network access, used Task Manager to End the Task (Microsoft Edge), started Edge, and cleared all the browsing content. Then I turned on the Network and ran Edge and there were no more virus infection messages. For good measure, I went to the installed Antivirs application, Bitdefender Free and started a full System Scan. A day and a half later and Bit Defender Free had finished with some strange message stuck on the bottom of the screen about imp.exe and a long string of hexidecimal numbers. I restarted the computer, and reviewed the Bitdfender status page and it said it had completed the virus scan without error. It said it scanned 2,223, 747 files with 0 infections. I then attempt to run the test and find that instead of the Audio server starting up, the command prompt comes up and declares that the application does not exist. I go to the DSP install directory, and sure enough, the Audio server application is missing. I have no way of figuring out what went wrong or where, but I do blame Microsoft and Bitdefnder, collectively, I have other experiences with both these corporations and their software that at times I wish there were much better alternatives to these evils.
I uninstalled Audio Weaver, deleted all of Matlab and and then went on to clean up the associated stuff that is in %appdata% and %programdata% related to these applications and then used CCLeaner to clean out the last bits from the registry.
I reinstalled Audio Weaver, using, Audio_Weaver_Designer_6.17.06_STMicro.exe, and then also ran, Audio_Weaver_Designer_6.17.06_STMicro_Update.exe, which does also does a proper regsvr32 AWETalkToGUI.dll.
Next, running Audio Weaver, whenever I click on the Refresh Target Info Icon, Audio Weaver crashes. It turns out that Bitdfender believes that Audio Weaver (probably as it is in it's own executable directory or because it speaks to the Audio server) is a malicious porgram so it terminates it. (I'm suprised it doesn't terminate Windows too ;-) ). I am able to add an exclusion to Bitdefener Free, after the fact and am now finally able to run Audi Weaver.
I use St-Link Utility, and successively load, run Audio Weaver, basic Layout and the results are mixed.
STM32F407_Discovery_EWARM.bin does not run the first time, I see the STM32F4 Discovery LED has turned solid and is not flashing solid. Odd, I press reset and it flashes slowly, I reconnect the Audio server and it flashes quickly and then refresh the traget infor and propgate the layout one more time and then run the layout and I get sound.
STM32F407_Discovery_MDK_ARM.bin runs without any anomolies.
STM32F407_Discovery_SW4STM32.bin does not run. After flashing with ST-Link Utility, with the soft and hard reset, the STM32F4 Discover LED never flashes and the AUdio Server cannot see the module on te USB port.
Now here is an interesting thing. I reflash STM32F407_Discovery_EWARM.bin, start Audio Weaver, using the Basic Layout I start playing some sound and then run Firefor to provide this report. The DESP engine running in the Stm32F4 Discovery module crashes, I know this because, the green LED is not flashing, it's stcuk on solid and the sound is now a single tone through the speakers. I tired a few more times and it appears that after a while, which seems to be a random time, the DSP engine build STM32F407_Discovery_EWARM.bin crashes.
I realize that I did not have to tell you about the Bitdfender Free and the Edge virus issues, but feel that were I to not tell you of these things the story would not be complete. I feel it's important for you to have a full picture.
I suspect that Bitdefender Free, while a reasobaly good product, being a free product has some deficienceies in its operation that interfere with development environment. Other folks may have also experienced simi;ar problems and not successfully circuvented the issues, thus this short missive should help those people out.
4:28pm
So I spent some more time observing the problem of DSP engine crashing in the module.
I flashed the STM32F407_Discovery_EWARM.bin file from the awe-bsp-stm32f407-discovery_10-7-2017.rar file and listened to sound without a problem from about 10 minutes.
I then flashed the STM32F407_Discovery_EWARM.bin file from the awe-bsp-stm32f407-discovery.zip file and after a minute or so, the DSP engine in the module crashes.
In case you're interested, I opened the project in SW4STM32 and it will not compile, ModuleList.h is messing.
I can only assume that you are changing the source code in all three development tools and creating three separate binaries.
As the SW4STM32 (System Workbench) binary never runs, I would be compelled to say that you have not yet landed on the problem with the source in that development tree.
4:49pm
This link: https://app.box.com/s/wjnakjdqyj1u7u3aqeufhvrjk4c3i79r
has been carefully tested for all 3 IDEs. They build and run from the IDE and the 3 binaries in the Bin file work when ST-Link is used to flash the board. If you are still having issues I might suggest doing a full chip erase in ST-Link before flashing the images.
9:30pm
Just to be clear, I have followed the instructions on Page 4 though to Page 6 in your manual,
Audio Weaver Target User's Guide - STM32F4xx Discovery.pdf
for the purposes of flashing the DSP engine into the STM32F4 Discovery, Model MB997B, every single time. In case I neglected to identify earlier, I am using STM32 ST-Link Utility, v4.1.0.0, STLinkUSBDrier.dll v5.0.2.0, and the St-Link V2 firmware is itself V2.J29.S0 STM32 Debugger.
I appreciate that you folks are going to extraordinary lengths.
7:34am
Testing here found the following version information:
ST-Link 4.0.0.2
STLinkUSBDriver 4.4.0.0
Firmware V2.J27.S0
8:11am
Upgraded ST-Link to the following:
ST-Link 4.1.0.0
STLinkUSBDriver 5.0.2.0
Firmware V2.J29.S0
Used this version of ST-Link. Connected to the board. Erased all of flash memory. Opened Bin\STM32F407_Discovery_SW4STM32.bin and flashed to the board.
8:15am
Started Designer version 6.17.06. Opened "Examples\AudioCheck.awd". Hit the "reconnect to target" button. Hit the "build and run" button, started Windows Media Player played some music for about 3 minutes. Found no issue.
4:40pm
I have uploaded the original distribution and the three archives you provided in this note.
You can access them here, https://1drv.ms/f/s!AgFM-PEsi4NsijHYQbA4GH9gMvGd
There is also a Text file with a summary of my test result for you to read.
You should know that my test environment was, the following DSP Concepts software, prior to its installation I uninstalled all of Audio Weaver, deleted all of Mathworks/MATLAB, and cleaned up everything related to this software in %Appdata% and %programdata%. I also ran CCLeaner and cleaned up the registry.
Audio_Weaver_Designer_6.17.06_STMicro.exe
Audio_Weaver_Designer_6.17.06_STMicro_Update.exe
For the life of me, I cannot explain the differences you are seeing from what I am seeing, but I am willing to send my module to you folks if you are interested.
------------------------------------------------------------------------------------------------------------------------------------------------
00-AWE BSP stm32f746 v1.2
- STM32F746_Discovery.bin - never ran
01-awe-bsp-stm32f407-discovery_10-7-2017.rar
- STM32F407_Discovery_EWARM.bin -runs for more than 10 minutes
- STM32F407_Discovery_MDK_ARM.bin - runs for more than 10 minutes
- STM32F407_Discovery_SW4STM32.bin - crashed after short time
02-awe-bsp-stm32f407-discovery.zip
- STM32F407_Discovery_EWARM.bin - crashed
- STM32F407_Discovery_MDK_ARM.bin - runs for more than 10 minutes
- STM32F407_Discovery_SW4STM32.bin - does not run produces a USB device error
03-awe-bsp-stm32f407-discovery_ST_version_10-7-2017.zip
- STM32F407_Discovery_EWARM.bin - crashed
- STM32F407_Discovery_MDK_ARM.bin runs for more than 10 minutes
- STM32F407_Discovery_SW4STM32.bin - does not run produces a USB device error
As an experienced Electronics Technologist, I have followed your procedure step for step to eliminate the problem of shortcuts that are always problematic. I know this from experience and trust that you appreciate this as well.
My experience with your product shows that immediately after it is flashed with ST-Link Utility to the STM32F4 Discovery, MB887B, the green LED starts a slow flash sequence with regular intervals upon a soft reset and also on a hard reset (black button proess). When the Audio Weaver Server connection is made to the DSP engine on the module, the green LED flash rate increases. When the Audio Weaver Designer has a valid layout and the run icon is clicked, the green LED flash rate appears to be keeping time to the music playing, or at least is rapidly randomly flashing.
When the DSP engine crashes or hangs, the sound either goes off or a single tone is heard, and the green LED is either on solid or off solid.
4:54pm
The "awe-bsp-stm32f407-discovery_ST_version_10-7-2017.zip" is the code I most recently verified works without issue for all three binaries for us. I have downloaded the posted 7z file and will flash the binaries in the "03-awe-bsp-stm32f407-discovery_ST_version_10-7-2017.zip" folder. If those binaries work for us indicating no corruption on transfer then I assume the difference must be in the version of Discovery boards or some issue on the computer. I will report my findings shortly.
5:23pm
Here are my results:
I installed the latest ST-Link utility on a virgin laptop (same version as you reported). I flashed the binary file Bin\STM32F407_Discovery_SW4S TM32.bin to our STM32F407 Discovery board MB997 C-01. After loading the AudioCheck.awd model and doing a build and run then playing an audio file with Windows MediaPlayer I heard no audio. Then I remembered that sometimes after flashing the board the CODEC doesn't reset properly. I unplugged both USB cables and plugged them back in and this time when I ran the model under Designer I heard audio as expected. While discussing hardware anomalies another issue I've experienced in the past is attempting to run the USB through two sets of USB hubs (meaning plugging one USB hub into a second USB hub and plugging that into the computer). It is best to plug directly into the laptop or into a single USB hub attached to the laptop.
At least proves that your binary is not corrupted...
4:24pm
I made an entry about this problem at STM, in the STM32 community forum, the following responses were posted there.
I am wondering myself about RCC differences and MCU core differences.
Is it possible that there was a bug in the core of the STM32F407VGT6 that was corrected from my MB997B to your recently released MB997C?
We know that each compiler will produce slightly different code from each other, is it possible that sufficient stack space does not get allocated in one or another compiler?
Could there be an issue with I2S timing differences?
Maybe, it is more cost effective to declare that only STM32F407 Discovery modules, part number MB997C and higher are supported?
Below is the conversation I started at STMicroelectronics.
https://community.st.com/message/171170-re-stm32f4-discovery-mb997b-and-...
11:42am
In my earlier link, https://1drv.ms/f/s!AgFM-PEsi4NsijHYQbA4GH9gMvGd , I have placed, en.DM00037591.pdf, an STMicroelectronics document that details a number of issues with the revision A chip on my MB997B module.
I suggest that it is not worth continuing to figure out this problem, it looks like a number of problems existed in the revision A silicon that I have.
12:24pm
From a recent entry at STM, a user says,
The RevA just doesn't want the prefetch enabled, but it's not remotely hard to identify
devid = DBGMCU->IDCODE & 0xFFF;
...
if (devid != 0x411) // 0x20006411 RevA 407 Prefetch broken
ws |= FLASH_ACR_PRFTEN;
..
/* Configure Flash prefetch, Instruction cache, Data cache and wait state */
FLASH->ACR = FLASH_ACR_ICEN | FLASH_ACR_DCEN | ws;
You can read the whole dialog here,
https://community.st.com/message/171426-re-stm32f4-discovery-mb997b-and-...