Project Zero 2 Wii Walkthrough

[Alfie Overacre]

Iexported a walkthrough but the video kept zooming in and out on its own. It's as if it was transitioning between videos or rotating on unknown axis. This happened for several project files, whereas for some other project files, the walkthrough turn out okay. I suspect that I messed certain things by playing too much in the navigation wheel and focal length, but I don't know how to reset the setting back to how it was. I also have tried creating new walkthrough but the result is still the same. It's also gives the same result when exporting as jpeg image.

I attached the link for the video for your reference. Have anyone had this problem before? Can anyone help me to identify what seems to be the problem?

If you select your walkthrough in plan view and click "Edit Walkthrough" on the ribbon, you should be able to have access to your frames and keyframes. As you modify your frames, the Active camera should indicate the focal length and direction.

I haven't try to make walkthrough using that 'problematic' project file in a while. What I did before was copy the whole thing in the project and paste it in a new project file. The walkthrough work out fine in the new project.

However, when I tried to make new walkthrough in the old project just now, it turns out just fine. I haven't even change anything yet. Still not sure what happened though, but I don't think its about walkthrough frame because I've never change the speed before. Thanks anyway.

Before I get into it I want to say a huge thank you to all who are on the forums and the Discord channel and a special thank you to @antisvin and @shensley for their thoughts on this write-up. Without the collective help and answers I would not be able to complete this write-up, nor get to this next level to build my upcoming sequencer.

Please note that I am new to embedded programming and this is my first deep dive into solving this type of problem. If anyone reads through this and has questions, please ask, and moreover if you see something incorrect or a better way to solve this please let me know.

This document is set up with sections discussing options on ways to manage the challenge of having a full FLASH. Each section is designed to be a standalone to help you try out the one idea and if that is enough, excellent. If not, you can try the next section.

Note: SDRAM is the slowest memory and should be used only if other sections are not suitable due to size limitations. You may also want to consider other optimizations such as using SDRAM for the larger storage and bring smaller sections into higher performance memory depending on your application needs.

One important note from this article is around initializing and class structure. You will need to have an initialization function that you call after the hardware init function. This is because the SDRAM needs to be setup for use before anything can be set in that memory location. If your background is from a Desktop programming environment, you may be used to setting variables at compile time. This does not work for external memory on these devices because the hardware initialization needs to be run so that the processor knows about the memory region and can use it correctly. This is why you will need to initialize your classes and variables after hardware initialization.

Once I started reading through this article I had to decide where I am going to boot from and how best to pick a way to boot during the development phase and what will work best when I ship my device? I decided to start with the SRAM boot loader. I may switch to QSPI, or write my own linker script, in my final version but that will be a write-up for another day.

Add in the following: APP_TYPE = BOOT_SRAM

This will have the build system use a new linker script that will move where the code goes into memory. This linker script will target loading code into the SRAM and DTCMRAM and this should give more coding space for most projects. We will discuss linker files later in this article if you wish to know a little more.

Reset the Daisy Seed

Notice: the new bootloader will go through a boot cycle of 2.5 seconds wait for a DFU connection and then go into its boot cycle looking for the other places to load code (e.g. SDCard, external USB, etc.). Read the Daisy Bootloader link at the top of this section for more information.

Note: there is an oddity that shows up for me when I first start debugging after I load up a new session. I reset the Daisy Bootloader bit the press and release reset and then press and release boot. The first time I go to debug the debugger takes a while to start up. During this time the Daisy ends up in the Bootloader looking for connections but is not running the code. I simply restart the deployment / debugging and this causes the project to rebuild, deploy via DFU, and then everything connects to and is ready to run and debug live.

A note as you read further through this document:

From here, this is where I only know enough knowledge to have solved my specific issue. This did work for me, and may help you as you go forward. Please note I am sure there are more options beyond this that may work well for you.

After a compile I always noticed there is the section saying how much of each memory type is used. I never really thought much of it until the day I got the FLASH is full and started reading through options on how to solve these issues.

(this sample comes from the Daisy Bootloader article)

As I was digging through articles and reading about the bootloader, I came across the discussion on the linker files and decided to dig into the linker file where it was showing the memory sizes and locations.

Digging more into the Mastering the GNU linker script - AllThingsEmbedded it did a great job of talking through what the different sections are. Here is a direct quote from the article on the different sections:

.text: This section contains the code. This is, the machine language instructions that will be executed by the processor. In here we will find symbols that reference the functions in your object file.

.rodata: This contains any data that is marked as read only. It is not unusual to find this data interleaved with the text section.

.data: This section contains initialized global and static variables. Any global object that has been explicitly initialized to a value different than zero.

.bss: Contains all uninitialized global and static variables. These are usually zeroed out by the startup code before we reach the main function. However, in an embedded system we usually provide our own startup code, which means we need to remember to do this ourselves. I wrote a nice article about the startup code a while back here.

Note: the BSS section is all about uninitialized memory. You will need to initialize your memory after the hardware initialization function is called because the external memory is not available to the processor until hardware initialization is complete. This is discussed in the article: libDaisy: Getting Started - External SDRAM (electro-smith.github.io)

Now that I understand there is a direct causation of the use of the macro adding the attributes to the object file and that those attributes help direct the linker to place the contents in a specific memory location I now wanted to see if I can redirect code from the DTCMRAM to the SRAM section.

It is important to know that there are specific tradeoffs in the type of memory one uses on these devices. In the stm32h750ib.pdf from STM32H750IB - High-performance and DSP with DP-FPU, Arm Cortex-M7 MCU with 128Kbytes of Flash memory, 1MB RAM, 480 MHz CPU, L1 cache, external memory interface, JPEG codec, HW crypto, large set of peripherals - STMicroelectronics

From Page 24, section 3.3.3 Embedded SRAM

RAM mapped to TCM interface (ITCM and DTCM): Both ITCM and DTCM RAMs are 0 wait state

ITCM and DTCM RAMS have very fast direct connections to the CPU whereas some of the other memories onboard the chip will be running slower than the CPU requiring wait states to fetch and store memory.

For me, I would like to ensure that my core processing of my main sequencer is running as fast as possible. This brought me to my next question: Can I target code files to go into specific parts of the system memory. It turns out the answer is yes. Read on if you wish to know more.

DMA user-provided buffers must be located in memory outside of the TCM memory.

SDMMC requires that any objects that interact with the peripheral (FIL, buffers, etc.) are located in the AXI SRAM (or the SDRAM).

You can specify a file name to include sections from a particular file. You would do this if one or more of your files contain special data that needs to be at a particular location in memory. For example:

data.o(.data)

If you use a file name without a list of sections, then all sections in the input file will be included in the output section. This is not commonly done, but it may by useful on occasion.

I was able to use this technique to target my core sequencer object file (seq.o) to run in the DTCMRAM. I did this by creating a new section towards the top of linker script to ensure the seq.o was prioritized to be put into the DTCMRAM early in the linker processing.

The result for me is that DTCMRAM usage started at 1.42% usage based on our previous change. Post the following change the DTCMRAM ended up at 68.99% usage and SRAM ended up at 37.06%! now my core data structures for my sequencers run at zero wait states to the CPU.

IIRC, CubeMX generates this sort of code and adapted version of it worked well for adding SD card support on Owlsy. This has some overhead as we have to perform an extra copy between different areas of memory, but it was necessary when memory gets allocated dynamically and can end up in any region.

Note that you have to modify startup file in order to get an extra .data section on SDRAM. And in order for it to work, SDRAM must be initialized before your firmware runs. This means that it can only work if you run bootloader first, otherwise SDRAM will be initialized by firmware at later time.

3a8082e126