SAM D5x based boards crash when using floating point operations

[wdevore]

When I upload the code to the feather-m4 it appears to crash. Double-resetting then shows the resultant blob on the device. I can restore the controller if I upload a known working program, for example, blinky. I have narrowed the code down to this:

package main

import (
	"fmt"
	"time"
)

func main() {
	i := 0.0
	for {
		s := fmt.Sprintf("%f", i) // "i" causes it to fail.
		println("flt: ", s)  <--- this causes the failure. remove this and it works.
		i += 1.0
		time.Sleep(time.Millisecond * 100)
	}
}

I was trying to do a simple ADC example and I can get it to work as long as I don't try to print floats but instead print int64s or something.
I don't have a JTAG setup so I can't see whats going on.

Any thoughts?

[aykevl]

Yes, most likely floating point is not enabled at startup while it is used by the program. We should either enable the FPU at reset or use softfloat instead.

I believe there is a potential current consumption issuse with enabling the FPU always but I think it's worth it to enable by default. It definitely shouldn't crash by default.

[aykevl]

For reference, here is the documentation: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/BEHBJHIG.html

(This is assembly, but it can also be written in Go).

[sago35]

I also crash when using float64 in tinygo0.12.0.windows-amd64 + pyportal (samd51) environment.
When building with docker's tinygo-dev, it did not crash, so I am using tinygo-dev now.

tinygo / tinygo-dev latest 359478e50f99 3 weeks ago 6.44GB

[deadprogram]

The probably means the current dev version works. The docker autobuild of the dev branch has been broken, which I am trying to fix now. But since that version is subsequent to the last release, it is probably working now.

[sago35]

It also crashes on 0.13.

tinygo version 0.13.0 windows/amd64 (using go version go1.13.8 and LLVM version 10.0.1)

[sago35]

What I'm wondering is why something built with tinygo/tinygo-dev in docker doesn't crash and
Does it crash when using windows tinygo?

By calling the enableCortexM4FPU() right after entering the main() function, windows tinygo doesn't crash anymore.
Tinygo/tinygo-dev in docker doesn't seem to be a problem either.

package main

import (
	"fmt"
	"time"
	"unsafe"

	"github.com/tinygo-org/tinygo/src/runtime/volatile"
)

func main() {
	enableCortexM4FPU()

	i := 0.0
	for {
		s := fmt.Sprintf("%f", i) // "i" causes it to fail.
		println("flt: ", s)       //<--- this causes the failure. remove this and it works.
		i += 1.0
		time.Sleep(time.Millisecond * 100)
	}
}

func enableCortexM4FPU() {
	// http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/BEHBJHIG.html
	cpacraddr := (*uint32)(unsafe.Pointer(uintptr(0xE000ED88)))
	tmp := *cpacraddr
	tmp |= (0xF << 20)
	volatile.StoreUint32(cpacraddr, tmp)
}

[sago35]

When reading CPACR by the following function, it looks like the following.
Why doesn't tinygo/tinygo-dev crash when CPACR == 0x00000000?

	docker tinygo/tinygo-dev	windows tinygo
tinygo ver	23e88bf	tinygo version 0.13.0 windows/amd64
CPACR	0x00000000	0x00000000

func readCPACR() uint32 {
	cpacraddr := (*uint32)(unsafe.Pointer(uintptr(0xE000ED88)))
	return *cpacraddr
}

[aykevl]

I have no idea why the development Docker container (tinygo-dev) doesn't result in a crash. It should produce nearly the same code after all (except for the small changes since the last release, none of which are floating point related).

[aykevl]

If you want, you can implement this by extending SCB_Type here:

tinygo/src/device/arm/arm.go

Lines 89 to 102 in a9ba6eb

	// System Control Block (SCB)
	//
	// SCB_Type provides the definitions for the System Control Block Registers.
	type SCB_Type struct {
	CPUID volatile.Register32 // CPUID Base Register
	ICSR volatile.Register32 // Interrupt Control and State Register
	VTOR volatile.Register32 // Vector Table Offset Register
	AIRCR volatile.Register32 // Application Interrupt and Reset Control Register
	SCR volatile.Register32 // System Control Register
	CCR volatile.Register32 // Configuration Control Register
	_ volatile.Register32 // RESERVED1;
	SHP [2]volatile.Register32 // System Handlers Priority Registers. [0] is RESERVED
	SHCSR volatile.Register32 // System Handler Control and State Register
	}

The documentation for that struct is here: it just needs a few more fields for Cortex-M4 (note that there is some space between some fields, which you can skip using a _ field).

Once you've added these fields, you can enable the FPU during reset here (just before or after preinit):

tinygo/src/runtime/runtime_atsamd51.go

Line 19 in 904fa85

preinit()

[aykevl]

Digging into this it appears that the release build produces slightly different binaries than builds I built locally or when linking with the Debian LLVM libraries. I suspect one uses floating point instructions while the other doesn't. This explains the difference between the release build and the tinygo-dev Docker container.

[aykevl]

Narrowed it down slightly further. Depending on the build (using Debian LLVM libs or manual build), the compiler-rt library is built slightly differently. So I can reproduce this issue locally without the release build.

[aykevl]

Found the issue, see: #1105.