Using an STM32H753, I have boot code in bank 1, sector 0 (0x08000000) that detects and jumps to application code in bank 2, sector 0 (0x08100000). In the application code I am trying to erase and rewrite bank 1 sector 0, but the MCU locks up (with no fault handler output) when I set FLASHH7_CR_START too soon after reset.
The application code is quite sophisticated and enables many features of the chip, but neither bank swapping nor FLASH CRC. The fault handler is known to work.
Things I have tried:
busy wait 50-100ms from reset before erasing; succeeds
redirect erase/rewrite to bank 1, sector 5; succeeds (without busy wait)
application code leaves caches disabled; still fails
compare FLASHH7 register bank at reset and 100ms later; no change
check errors in SR and clear any detected with CCR; no errors found
check WRP and PRAR registers; no protection set
check errata rev6 (19 Jun 2019); no relevant issues
The boot code does not enable any interrupts or caches and the application code writes to VTOR.
It seems there is something else time-sensitive about erasing the STM32H7 boot sector (or recently executed sector). What am I missing?
Posting as an answer because of the image.
As I suspected. Probably silicon bug
this from the errata pages. Check your uC model (which you actually hide :) )and download errata for your one.
Related
I have the problems with both SAVIHost v1.43 and VSTHost v1.57 for the case of Dexed 0.9.6. As I am a hobbist only, related to both MIDI and IT, I wish to ask some help to overcome these problems detailed below.
My problem with SAVIHost V1.43:
I copied savihost.exe (extracted from savihost3x64.zip) copied into directory "C:\Program Files\Common Files\VST3" (i.e. into the installation directory of Dexed.vst3) then renamed it to Dexed.exe, and launched this Dexed.exe.
I set "loopMIDI Port 1" (created prior by "loopMIDI v1.0.16 (27)") as "Input Port 1" via "Devices|MIDI..." and "1764 samples (25 b/s)" via "Devices|Wave...". (The sample rate was 44100 Hz, and both ports were "MME: Microsoft Sound Mapper).
Then I played some sounds by use of the virtual keyboard, and changed Dexed's programs (instruments) randomly - and Dexed seemed to work well, it played the different sounds with the actually selected instruments. Then I sent some MIDI Messages by Cakewalk by Bandlab to "loopMIDI 1"; Dexed produced the appropriate sounds, according to MIDI Note On/Off messages received - except that all the MIDI Program Change messages (C0 xx) were ignored.
Finally, when I clicked onto icon of Dexed.exe (i.e. renamed savihost.exe) in the Windows 10 Taskbar on the screen: the main window of Dexed.exe was minimized,
but when I clicked onto its icon again, although its main window is restored but crashed immediately. A dialog titled as "Dexed" appered,
containing an error message:
Unhandled exception 0xC0000005 at 00000014005BEBA
reading from FFFFFFFFFFFFFFFF
(followed by a list of the recent content of registers).
Furthermore, I noticed that resizing of window of Dexed.exe (moving its bottom edge upward) also causes a crash, but only after when Dexed.exe received some MIDI messages through "loopMIDI Port 1".
(i.e. playing on virtual keyboard, followed by similar resizing did not cause crashes - at least, I have not realized that.)
The situation was ditto for the case of SAVIHost V1.44 beta.
Problem with VSTHost V1.56 x64:
In the second case, I started VTSHost.exe, then loaded Dexed.vst3 via File|New Plugin... . Dexed.vst3 also seemed to work well at the beginning, i.e. while I played on the virtual keyboard bar, and changed the programs (instruments) and modified some parameters by the knobs on the screen. But when VSTHost received the first MIDI messages through the "loopMIDI Port 1", Dexed does not played any notes anymore. Instead, some extra message lines appeared in the dialog "Info" below the line "Chained as Insert before 1: Engine Output":
...
Processing is turned off (errors in PlugIn?)
ProcessReplacing
Exception 0xC0000005 at 000000014007ABF6 reading from 0000000000000000
...
Stack Trace:
...
Unfortunately, the situation was the same in case of VSTHost V1.57 beta x64.
Comments:
Dexed.vst3 worked without problems in case of other VST host apps (e.g. CakeWalk by BandLab and Cantabile 4 Lite), i.e. also the MIDI Program Change messages were executed properly.
(CakeWalk by Bandlab used Dexed.vst3 directly, Cantabile 4 Light received MIDI messages from CakeWalk by BandLab through "loopMIDI Port 1".)
similarly, the original standalone Dexed application also processed the MIDI Program Change messages through "loopMIDI Port 1" correctly.
version number of Dexed.vst3 reported as 1.0.0 by VSTHost (although is is originated from unzipping of "dexed-0.9.6-win.zip").
my PC has the followings:
-- OS: MS Windows 10, 22H2, build: 19045.2311 (x64)
-- CPU: Intel(R) Core(TM) i5-4460 CPU # 3.20GHz
-- RAM: 8 GB
-- motherboard: Gigabyte Technology Co., Ltd. B85M-D2V
-- sound: Realtek, High Definition Audio (on-board)
Finally, I wish to mention that I have tried other VSTs than Dexed's one with both SAVIHost and VSTHost: "sforzando.vst3" and "Roland Sound Canvas VA.dll".
There were no problem at all - no interception of any MIDI Message, no crash, etc -, they had been worked without any problem for hours. So I am not really sure, what and where are the root of the problems above: maybe in SAVIHost or VSTHost - or maybe in Dexed.
I wish ask some help, how I shall continue to determine, which component - ie. savihost/svthost or Dexed - is failed and resulted the problem?
Thank you very much for you kind efforts in advance!
I am writing an external bootloader for the STM32F730Z8 - (why? I need one windows code that can run the bootloader for the STM32, or use the STM32 to reprog a connected ATF1508 for my client). I've done this before, using info in AN3155 and AN2606. On lesser CPUs, this has had no difficulty (i.e. STM32L4P5). In this case, I try the same:
1-cycle \RESET & BOOT0 to boot to supervisor mode
2-autobaud successfully
3-send 0x00 to get the list of commands, successfully
4-send 01 to get the version and protection, successfully (vers 49, rp and nt both 0)
5-send 02 to get chip id (0x0452), successfully
6-send 0x73 to write-unprotect flash, successfully (i.e. receive back two ACK)
7-send 0x44 to begin an extended erase (intending only to erase sector 0).
This is where it fails. I get neither ACK nor NACK - it just times out. I don't even get to the second half of the extended-erase command where I send it the sector info. (On the STM32L4P5 it succeeds here easily and goes on to finish erasing, then to write code successfully.)
I've tried very long waits & repeat loops to wait for the ACK (many minutes). From past experience this should be fast, it is only the second stage where I tell it how much flash to erase that takes any significant time.
I've inspected the protection option areas of memory, at 0x1FFF0010, 0018, and they are unprotected, as per factory defaults.
I'm communicating over an FT231XS-R, using the D2XX driver calls. I can mess with the baud rates and such, but that only prevents it from autobauding...and we're doing that fine (9600/8/1/E). I've played with the D2XX SetTimeouts - if set too hasty that only screws up earlier commands. I'm wired to a 20 MHz crystal, and the application runs at 200 MHz, but my understanding is that the bootloader just runs at the internal RC clock rate.
I'm certainly missing something stupid, but I didn't see it in the documentation. Help?
Jeff Casey / Rockfield Research Inc. / Las Vegas, NV
Fixed, disregard.
The fineprint of AN3155 clued me in. On the description of the Write Unprotect command, it says that a system reset will be performed after completion. How did I miss this on the STM32L4P5? I just didn't read it. But why did it work then? In the really fine print next page, in a footnote to the flowchart, it says that they were just foolin'....system reset is only called for some (..list omitted..) and for other STM32 products no system reset is called for.
My earlier success had the following sequence:
reboot-supervisor
autobaud
get
gvrp
gid
wpun
xerase
wpun
write
verify
reboot-user
obviously that doesn't work for the F730. what works is:
reboot-super
autobaud
get
gvrp
gid
wpun
reboot-super
autobaud
get gvrp
gid
xerase
reboot-super
autobaud
get
gvrp
gid
write
verify
reboot-user
(obviously I can skip a few of the repeated steps, like get-id, but basically it needed a reboot and re-autobaud.)
note that i had to reboot-super a 3rd time...this was because the write attempt timed out after the xerase unless i went through the whole sequence again. funny, though, the spec doesn't say anything about resetting after an erase. i cross posted this question on the STM32 community site, and I'll do the same with this answer and ping them on this.
Thanks for reading, cheers. Jeff
Computer System Architecture - Morris Mano In chapter 5 section 7 figure 5-13
When IEN it checks whether "FGI" or "FGO" are set to 1 then an interrupt cycle happens, but as I know is when FGI = 1 it means that information in INPR cannot be changed, and FGO is the reverse to that which means that when FGO is set to 1 then information in AC will be transferred to OUTR 'OUTR can be changed' so the question here shouldn't the condition of applying interrupt cycle happen when "FGI" = 0 or "FGO" = 1 since INPR or OUTR can be changed under these conditions which now make since to execute an interrupt?
Either flag being 1 logically means a device is "ready", but what "ready" means differs for input and for output devices. In either case, flag being 1 means that the processor can or should now take action.
FGI=1 means the input device is ready, but that really means a new input is available (e.g. the user typed a key on a keyboard) and the processor should accept it. FGO=1 prevents the input device(s) from overwriting a prior input held in INPR that the processor hasn't accepted yet. When the processor accepts the input, FGI goes to 0 unlocking the INPR register, and that allows the input device to write again, which it will eventually do when the user presses another key (sending FGI back to 1 to signal the processor).
FGO=1 means ready for output, which really means the last output has been fully accepted by the device, so the OUTR register is unlocked for the processor to write a new data (character for the console). FGO=0 prevents the processor from writing OUTR as the output device hasn't accepted the last one yet.
The interrupt service routine should check each flag, and if FGI=1 then accept an input (INPR->AC) and move it into a buffer for the user program to read when it is ready. Whereas if FGO=1, then move an output character from memory buffer into the AC, and then do AC->OUTR, also lowering FGO to 0, which will preclude the processor writing until that data has been accepted by the device.
So, FGI=0 means that the processor has accepted the prior INPR value provided by the input device, and there is no new character as yet but the register is unlocked so the device can write at will.
FGO=0 means that the processor has written a value to the OUTR register, but the output device hasn't accepted that yet, so the register should be considered locked.
I want to understand meaning of the following function mode definition, there is explanation in the library. But I don't understand that because explanations are very short and not enough. I searched on the net I couldnt find any information about.
CAN_InitStructure.CAN_TTCM = DISABLE;
CAN_InitStructure.CAN_ABOM = DISABLE;
CAN_InitStructure.CAN_AWUM = DISABLE;
CAN_InitStructure.CAN_NART = ENABLE;
CAN_InitStructure.CAN_RFLM = DISABLE;
CAN_InitStructure.CAN_TXFP = ENABLE;
These are the names of the bits located in the CAN master control register (CAN_MCR). So, the proper source for their meaning is the reference manual. My following answer will be somewhat copy & paste from the reference manual, but I will try to explain these bits in detail.
TTCM (Time triggered communication mode): This bit activates the Time Triggered Communication (TTCAN) mode, which is an extension to the CAN standard. I don't know much about TTCAN, but as I understand, it assigns time windows to messages to satisfy some real-time requirements. So, normally this bit should remain 0.
ABOM (Automatic bus-off management): If the transmit error counter (TEC) becomes greater than 255, the CAN hardware switches to bus-off state. To recover, it must wait for the recovery sequence, 128 occurrences of 11 consecutive recessive bits. Only after that, the CAN hardware may return to the normal operating state. This bit controls the returning behavior. If it's 1, returning to normal state is automatic. Otherwise, software should make the request, provided that the recovery sequence has been observed.
AWUM (Automatic wakeup mode): The CAN module can be in one of 3 modes: Initialization mode, normal mode or sleep (low power) mode. Sleep mode is requested by the software. However, you have 2 options to exit sleep mode. If this bit is 0, then you have to exit sleep mode manually. You may enable CAN wakeup interrupt to inform you about bus activity, then exit the sleep mode in ISR. But if this bit is 1, the hardware returns to normal mode automatically when it detects bus activity.
NART (No automatic retransmission): Normally, CAN hardware retries to transmit a message if its previous attempts fail, because of arbitration lost etc. But if you make this bit 1, the transmitter does not retry. This is required when you use Time Triggered Communication (TTCAN). Otherwise, you should keep this bit 0.
RFLM (Receive FIFO locked mode): Your receive mailboxes have 3 levels depth, meaning that they can store maximum 3 messages before they are overrun. This bit controls what happens in case of mailbox overrun. Default behavior is to keep the oldest 2 messages and the newest one. For example, if you received 5 messages, the buffer keeps the messages 1, 2 & 5. However, if you make this bit 1, the mailbox keeps the messages 1, 2 & 3 and discards the new arrivals.
TXFP (Transmit FIFO priority): You have 3 transmit mailboxes. When you fill more than one, the hardware must decide which one to transmit first. Normally, one can assume that a message with a lower ID number is more important and should be transmitted first. But if you want to transfer them in a first-comes-first-served fashion for some reason, you need to make this bit 1. Of course, this is just a local priority. On the physical bus, the messages with lower ID always have priority.
We have an virtual audio device driver similar to Sound flower. This virtual device will be listed in sound system preferences. Whenever our device gets selected in system preferences, it prevents idle sleep. If we switch the selection to default output device, everything works as expected.
If we execute 'pmset -g assertions' command in Terminal, it gives below output
Assertion status system-wide:
ChargeInhibit 0
PreventUserIdleDisplaySleep 0
PreventUserIdleSystemSleep 1
NoRealPowerSources_debug 0
CPUBoundAssertion 0
EnableIdleSleep 1
PreventSystemSleep 0
DisableInflow 0
DisableLowPowerBatteryWarnings 0
ExternalMedia 0
Listed by owning process:
pid 115: [0x0000012c00000073] PreventUserIdleSystemSleep named: MY_DRIVER_IDENTIFER.noidlesleep"
Could any one suggest me some pointers to resolve this issue.
I think this governed by the flag kIOPMPreventIdleSleep, which resides in the capabilityFlags field of the IOPMPowerState struct.
To participate in power management decisions, you'll need to add your device driver to the power management plane, typically in your overridden IOService::start(provider) method:
PMinit();
provider->joinPMtree(this);
registerPowerDriver(this, powerStates, numPowerStates);
where powerStates and numPowerStates specifies an array of power states you want your device to be able to be in. You'll probably not want more than 2 for a virtual device, and maybe you even only need one. I suspect a superclass of your class is setting states that are inhibiting sleep. Once you've registered for power management, your driver will be expected to handle the power management methods such as IOService::setPowerState().
Depending on how you want your device to behave, you might want to create 2 power states, one "live" when playing back or capturing sound (and inhibiting sleep) and the other "idle" when the device isn't doing anything, and allowing sleep.
The power management topic is a bit too big to cover entirely in a StackOverflow answer, so I suggest you read the docs on the stuff I've mentioned above and try clearing the relevant flag in your power state(s).
Hope that helps.