connection problems with HY-MINISTM32V 3.2

connection problems with HY-MINISTM32V 3.2" only works in Windows 7 and Linux with the HY - MINISTM32V firmware 2.4". Windows with the HY - MINISTM32V firmware 3.2 "detects the plate but not connected and Linux mint does not detect it

tested 22.4.2014
Greetings I hope to be of help

I think there are some problems with new Espruino versions on the HY board I'm afraid (it only boots up sometimes). You could try Espruino 1v44.

Some people were trying to fix this, but it all went a bit quiet.

Hello Gordon and changed the source of code and it works. and changed the following files: line 76 usb_conf.h and changed jswrap_json.c/h vesion 22.4.2014 .
works, but the failure of screen(display shows rain)

a greeting
modified attached code
http://picfacil.net46.net/Espruino-maste­r_23_4_2014.7z

Hello again here I put the changes in detail

usb_conf.h
before

[#define](https://forum.espruino.com/sea­rch/?q=%23define) IMR_MSK (CNTR_CTRM  | CNTR_WKUPM |/* CNTR_SUSPM | CNTR_ERRM  | */CNTR_SOFM | /*CNTR_ESOFM |*/ CNTR_RESETM )
After
[#define](https://forum.espruino.com/sea­rch/?q=%23define) IMR_MSK (CNTR_CTRM  | CNTR_WKUPM | CNTR_SUSPM | CNTR_ERRM  | CNTR_SOFM | CNTR_ESOFM | CNTR_RESETM )

jswrap_object.c
before

/*JSON{ "type":"method", "class": "Object", "name" : "hasOwnProperty",
         "description" : ["Return true if the object (not its prototype) has the given property.","NOTE: This currently returns false-positives for built-in functions in prototypes"],
         "generate" : "jswrap_object_hasOwnProperty",
         "params" : [ [ "name", "JsVar", "The name of the property to search for"] ],
         "return" : ["bool", "True if it exists, false if it doesn't"]
}*/
bool jswrap_object_hasOwnProperty(JsVar *parent, JsVar *name) {

  JsVar *propName = jsvAsArrayIndex(name);

  bool contains = false;
  if (jsvHasChildren(parent)) {
    JsVar *foundVar =  jsvFindChildFromVar(parent, propName, false);
    if (foundVar) {
      contains = true;
      jsvUnLock(foundVar);
    }
  }

  if (!contains) { // search builtins
    char str[32];
    jsvGetString(propName, str, sizeof(str));

    JsVar *foundVar = jswFindBuiltInFunction(parent, str);
    if (foundVar) {
      contains = true;
      jsvUnLock(foundVar);
    }
  }

  jsvUnLock(propName);
  return contains;
}

After

/*JSON{ "type":"method", "class": "Object", "name" : "hasOwnProperty",
         "description" : ["Return true if the object (not its prototype) has the given property.","NOTE: This currently returns false-positives for built-in functions in prototypes"],
         "generate" : "jswrap_object_hasOwnProperty",
         "params" : [ [ "name", "JsVar", "The name of the property to search for"] ],
         "return" : ["bool", "True if it exists, false if it doesn't"]
}*/
bool jswrap_object_hasOwnProperty(JsVar *parent, JsVar *name) {
  char str[32];
  jsvGetString(name, str, sizeof(str));
  //JsVar *propName = jsvAsArrayIndex(name);

  bool contains = false;
  if (jsvHasChildren(parent)) {
    JsVar *foundVar =  jsvFindChildFromVar(parent, str, false);
    if (foundVar) {
      contains = true;
      jsvUnLock(foundVar);
    }
  }

  if (!contains) { // search builtins
    
    //jsvGetString(propName, str, sizeof(str));

    JsVar *foundVar = jswFindBuiltInFunction(parent, str);
    if (foundVar) {
      contains = true;
      jsvUnLock(foundVar);
    }
  }

  //jsvUnLock(propName);
  return contains;
}

functional today
a greeting

Guess that was me. Some false assumption about the time on hand. Then again, if waiting works that well...

Would be nice to have that fix in the next build and maybe your 23.4. build somewhere where it actually downloads (I know, complains... But still, I seem to get only single bits from that link above)

Thanks for looking into into fixing that USB thing.

I'm not sure those changes will really help - are you sure it works reliably after applying them?

• Even if USB is broken, you could always connect to the USB connector you used to flash and everything would be fine. I think it's unlikely it is broken though as it's the same chip as the Espruino Board - and those lines were changed intentionally as the USB wasn't reliable (and interrupted every msec) with them in.
  
• jswrap_object_hasOwnProperty won't be used at all unless it is explicitly called, and your changes break it anyway.
  

hey gordon,
the 1v44 file does not seem to exist at the location you posted.
1v41, then 1v45 exist.

There's a http://www.espruino.com/files/espruino_h­ystm32_32_vc_1v43_beta.zip though.

Thanks - sorry, I'm not sure what happened there. 1v45 might work ok?

Whitelit my both boards yesterday anyway, when trying to reflash them using my macbook.

Don't even know what to try next nor why it failed :/ So erase seems to have worked... Despite the script saying otherwise.

Would "stlink" do the task instead of that python script?

What can we do to have all the processes becoming more stable and maybe even supported?

Whitelit?

st-link is for the discovery boards that have a programmer on-board, not for the HY-STM32... The python script is very reliable usually - are you sure you've got it plugged in the right USB connector and have reset into bootloader mode properly?

I really don't know what to suggest. This is why we have the Espruino board. All the boards are the same, they're tested, and I can develop software that works reliably with them.

Gordon,

I agree that your board is fun and reliable, especially cool with the HM-10, and I recommend it to anybody I meet. But since I needed that touch screen instead of the power saving and battery features (which are amazing) right now...

Whitelit meaning the display just being white and lit when plugging in a USB cable. Before it played the colorful touch screen demo the board comes preinstalled with.

USB ist the correct one, as its the only one that shows up as a usb serial port. (and that's only if you install the PL2303 drivers for Mac OS X. Not sure if that was mentioned anywhere.) And of course it erased the flash successfully, so...

I coded a quick tool to see what's going on on the Serial Port, and it seems that some responses by the board are coming in too slow. Not sure if it's the board or the driver or some weird flow control issue that's the problem here. From what I saw, I would guess that the Python script might get confused when it gets incomplete input or the last bytes from an earlier command. I also get additional zero values at the end when reading board memory in larger chunks. Very weird.

I'll see if I can make the tool write something to the board and have the board flashed using the tool, now that have most of the talking to the board in place.

If anybody has an alternative driver (I have the PL2303_MacOSX_v1.5.1.pkg running under Mavericks), please let me know.

Frankly I see the HY3.2 as an interesting board, and I'd love to pay a licence fee for Espruino (and read your disclaimer in the readme) if Espruino would be supported on this useful board that doesn't seem to come with any those "not for product development" licences if I understand it correctly.

Short update:

I managed to flash my board from my mac using the mentioned tinker tool.

However, i found:

The boot button on one of the boards being defective.

The CRC seed (Bootloader version 0x22) seems different from that in the python script.

The Serial device having "late" bytes coming in, filling the buffer but not triggering a "data available" event. (Have to determine on what level that bug occurs)

Zeros being added to memory readouts for readout chunks sizes close to 256 Bytes (sometimrs resulting in some 400 Bytes instead of the expected 256)

I used a very controlled (and unoptimized approach) for flashing the data onto the board which took 2h or so because of all the waits and checks, but the board now boots into 1.45.

I'll see what i can take from that, test it on another machine and do some profiling on the delays to get a more optimized version .

Still hope that it's something stupid that can be fixex easily, however.

Will switch the boot0 switch, too ...

@Stev - it sounds to me like you may have some other software using that serial port? Have you tried on a different computer?

The serial bootloader itself is built into the STM32 in read-only memory, so either the STM32 chip is defective (seems unlikely) or something else is padding those bytes out.

Of course I guess it could be a hardware fault - maybe the connections between the STM32 and the PL2303 are a bit flaky?

@Gordon
At least I get the bins onto the board now :) I can get around the zeros by lowering the chunk size to 128 or something. Using the same chunk size for writing to the board.

I will look into that serial issue in more detail later on, and maybe get the original script to work reliably with the board. I have collected a few alternative serial drivers for OS X and might also look into Xojo's serial handling (which I used to be cross platform, but it seems to have its own "characteristics" and best practices that need to be obeyed).

Still, I now can confirm that in your builds/files 1.48 is the last working version (the ones after don't react to any of the USB serial ports and don't display anything on boot) and that alexrlopez86's build of 1.62 boots up the board, displays the bootup text on screen and allows access via both USB serial ports. Perfect. For now.

I haven't had the time to look at his code, so I can't say right now, whether it's his changes to the USB flags, or just his own build that make it work. But it boots up the board, so I can finally come back to the actual usecase :)

So, maybe you can incorporate the changes? Or just do a build with your tool chain?He seems to have archived the complete checkout with changes, so it might not be that much of a task. Thanks again for all your responses to the weird serial port probs. Kept me looking at the issue.

And thanks again to alexrlopez86, keep the builds coming :) (Have you tried whether a build on your toolchain without any changes would create a running build?).

Cheers
Stev

@Gordon

BTW, I am not so enthusiastic about that display anymore, now that I have it running :)
So if you consider sourcing some nice display and touch that runs well with your own board, I would consider that a big win. (After all, I never had any trouble uploading the latest build to your own boards :)

Cheers
Stev

That's great! @alexrlopez86 can you just try a built without any changes as @Stev suggests? It is possible it's the compiler I'm using that is causing the issues.

Sadly I can't pull in the changes unless I #ifdef them out for the Espruino board - each of the two changes breaks something :(

Why not so enthusiastic about the display now? I have to say I haven't tested in a while, but I didn't think it was too bad. While it shouldn't be a big deal to have those kinds of displays working with Espruino, I think any 16 bit colour touchscreen displays that you can buy for this kind of task will all be very similar quality...

Hm. The colors and brightness change a lot depending on the angle and the greys, or partially lit colors (e.g. when you draw a gradient) tend to create line flicker.

Full colors and black are ok though.

But you're probably right, when you say that this is what you get for the price (unfortunately the next quality step comes with a big jump in price). Still I wonder if there might be some good kickstarter/community projects coming up that might be as useful as the cc3000 and wiznet. It's an important part of interaction with the world. So, just a wish for now :)

Hi,

I would recommend to try this
http://www.ebay.com/itm/3-5-TFT-LCD-Modu­le-Display-for-Arduino-PCB-adapter-Touch­-Panel-/130953756581?pt=LH_DefaultDomain­_0&hash=item1e7d73bfa5

It's IPS and it is really different. I own both this one and HY32

Hey,

Cool.
Is it pin compatible, so that I just can replace the original one?
And could I drive it using the Espruino-Board instead (I found thy HY32 so convenient, as I didn't have to care about packaging the components and didn't have to look at the connector specs.). I would happily swap the large board for Gordon's.

Cheers
Stev

Nope, definitely not pin compatible, they use a different controller. The one linked uses ILI9481, and there is no module for it (yet), though it's probably similar to the 9341-.-for which we do have a module

Internally there's support for the chips used in the HY boards (but not the 9481), they're all amazingly similar though so modifying the 9481 driver should be easy. It just depends whether it can be put into SPI mode (which is likely) - trying to wire up 16 bits + the rest is no fun at all :)

Sorry, no. They aren't pin compatible. I just use a bunch of jumper wires

And I also use FMSC to drive the bus. Gordon's board contains chip from medium-density series, so it does not have FMSC. But it's not really a problem. It can be driven by bit banging (if you have enough free pins)

Let's count. You need WR, RD, CS, A0 and either 8 or 16 data bits for display and CS, MCK, MISO and MOSI for touch

ILI9481's are slightly different in how you setup registers to access controller memory

Using of SPI is possible but slow. The maximum SPI clock you can have from STM32F103 is 18MHz, which is 2MB/s. The maximum not yet exeeding spec FMSC speed is 8MB/s. There's compromise solution - use 8 bit mode

Ok, there goes the convenience :) The connector looked so promising similar to the one of the HY board. Still, there should be enough pins on the HY board due to its original display's need and even the original Espruino might just have enough pins left, as I only need two SPI sets plus those data lines right now. Would be nice if it would run with the original Espruino board.

What's the actual speed of the display when using your driver code? The one that comes with the HY is neatly fast and fun, especially to use compared to the SPI-only ILI I use with Gordon's board right now (because of the CC3000). Behaves more like a Etch-a-Sketch than a display.